Google unterstützt in Chrome seit Version 58 (von 2017!) Feld „Common Name“ in SSL/TLS-Zertifikaten nicht mehr. Gleiche gilt für Firefox seit Version 98 und mittlerweile auch alle anderen Browser.
Firefox und Chrome melden: SSL_ERROR_BAD_CERT_DOMAIN
Die Windows Zertifizierungsstelle (Windows CA) mit dem Template „Webserver“ füllt dieses Feld allerdings nicht automatisch. Daher muss man bei Zertifikatsanforderungen das Attribut manuell hinzufügen und die CA dafür konfiguriert haben.
Warum? Das CN-Feld wird verwendet, um den Domänennamen anzuzeigen, für den das Zertifikat gültig ist. Der reine CN als Identifikationsmerkmal wurde allerdings vor fast zwei Jahrzehnten per RFC abgeschafft, das Feld ist viel zu unflexibel (keine Wildcards, keine Multidomains …). Die heute genutzten Felder sind „DN=“ und „SAN=“ (DNS-Domain) – warum die noch immer nicht in Microsoft’s Standard-Templates enthalten sind ist ein Geheimnis.
Lösung
Man muss der CA zuerst beibringen, den „Subject Alternate Name“ (SAN) überhaupt nachträglich zur Anforderung hinzuzufügen. An einer Administrator-CMD-Shell geht das so:
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc
Ab dann kann (=muss) man den Anforderungen den SAN als „san:“ Attribute bei der Beantragung mitgeben.
Lösung (Web Zertifizierungsstelle)
Im Feld „Zusätzliche Attribute“ können einer oder mehrere SANs mit „&“ getrennt angegeben werden:
san:dns=SERVERNAME.EXAMPLE.COM&dns=SERVERNAME2.EXAMPLE.COM
Lösung (Kommandozeile)
An der Kommandozeile sollte im Auftrag (*.inf) das Attribut einfach bereits unter „[RequestAttributes]“ enthalten sein:
[RequestAttributes]
CertificateTemplate = Webserver
SAN="dns=SERVERNAME.EXAMPLE.COM"Dann kann man das Zertifikat ganz normale Requeste werden:
certreq -submit -attrib "CertificateTemplate:Webserver" CSRDATEINAME.req ZERTIFIKATAUSGABEDATEI.cer