Vraag Moet een wildcard SSL-certificaat zowel het hoofddomein als de subdomeinen beveiligen?


Ik stel deze vraag, omdat Comodo me vertelt dat een wildcard-certificaat voor * .example.com ook het hoofddomein example.com beveiligt. Dus met een enkel certificaat zijn zowel mijn.voorbeeld.nl en voorbeeld.nl zonder waarschuwing beveiligd in een browser.

Dit is echter niet het geval met het certificaat dat ik heb gekregen. Mijn subdomeinen zijn goed beveiligd en geven geen foutmelding, maar het hoofddomein genereert een fout in de browser en zegt dat de identiteit niet kan worden geverifieerd.

Wanneer ik dit certificaat vergelijk met andere soortgelijke scenario's, zie ik dat in de scenario's die foutloos werken, de SAN (Subject Alternative Name) zowel * .example.com als example.com vermeldt, terwijl het recente certificaat van Comodo alleen een lijst * bevat. example.com als de algemene naam en NIET example.com als de alternatieve alternatieve naam.

Kan iemand bevestigen / verduidelijken dat het hoofddomein in SAN-details moet worden vermeld als het ook op de juiste wijze beveiligd moet worden?

Wanneer ik dit lees: http://www.digicert.com/subject-alternative-name.htm Het lijkt erop dat het SAN beide moet opsommen om te kunnen werken zoals ik het nodig heb. Wat is jouw ervaring?

Heel erg bedankt.


71
2017-09-12 16:12


oorsprong




antwoorden:


Er is enige inconsistentie tussen SSL-implementaties over hoe ze jokertekens matchen, maar je hebt de root als alternatieve naam nodig om met de meeste clients te werken.

Voor een *.example.com cert,

  • a.example.com zou moeten passeren
  • www.example.com zou moeten passeren
  • example.com zou niet moeten slagen
  • a.b.example.com kan doorgaan afhankelijk van de implementatie (maar waarschijnlijk niet).

In wezen zeggen de normen dat het * moet overeenkomen met 1 of meer niet-punt-tekens, maar bij sommige implementaties is een punt toegestaan.

Het canonieke antwoord zou moeten zijn RFC 2818 (HTTP Over TLS):

Matching wordt uitgevoerd met behulp van de overeenkomende regels gespecificeerd door     [RFC2459]. Als er meer dan één identiteit van een bepaald type aanwezig is     het certificaat (bijv. meer dan één dNSName-naam, een overeenkomst in eender welk     van de set wordt als acceptabel beschouwd.) Namen kunnen het jokerteken bevatten     teken * dat wordt geacht overeen te komen met een enkele domeinnaam     component of componentfragment. bv *.a.com komt overeen met foo.a.com maar     niet bar.foo.a.com. f*.com komt overeen met foo.com maar niet met bar.com.

RFC 2459 zegt:

  • Een "*" jokerteken KAN worden gebruikt als de meest linkse naam   component in het certificaat. Bijvoorbeeld, *.example.com zou   overeenkomen met a.example.com, foo.example.com, enzovoort, maar komen niet overeen   example.com.

Als u een certificaat nodig heeft om bijvoorbeeld example.com, www.example.com en foo.example.com te gebruiken, hebt u een certificaat met subjectAltNames nodig, zodat u "example.com" en "* .example.com" (of voorbeeld .com en alle andere namen die u mogelijk moet matchen).


64
2017-09-12 16:33





U hebt gelijk, het hoofddomein moet een alternatieve naam zijn om te valideren.


11
2017-09-12 16:34





Elke SSL-provider die ik ooit heb gebruikt, voegt het hoofddomein automatisch toe als een alternatieve alternatieve naam aan een wildcard-SSL-certificaat, dus DOMAIN.COM zal automatisch werken voor een * .DOMAIN.COM-wildcard cert.


4
2018-04-22 22:34



Dit geldt niet voor AWS Certificate Manager vanaf 2017-09-20. - pho3nixf1re
Er is geen "de" hoofddomein voor een SAN-certificaat dat meerdere hoofddomeinen kan beveiligen. - Jez


Wildcard-certificaten worden ideaal gegenereerd voor * .example.com Om uw subdomeinen en domeinen met dit certificaat te beveiligen, hoeft u alleen hetzelfde certificaat te installeren op servers die naar deze domeinen verwijzen.

U hebt bijvoorbeeld een jokertekencertificaat voor * .example.com one.example.com - server 1 voorbeeld.com - server 2

u moet dit certificaat installeren op server 1 en server 2.


-2
2018-04-14 08:17