Chrome blockt Zertifikate mit Common Name

Um zu testen, ob ein Zertifikat zum Server-Namen passt, den der Anwender aufruft, vergleicht der Browser die Namen. Es war lange Zeit Usus, dazu den Namen des Servers – etwa www.heise.de – im sogenannten Common Name (CN) des Subject-Felds anzugeben. Allerdings hat der im Jahr 2000 veröffentlichte RFC 2818 davon bereits abgeraten:

"Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead."

Mit Chrome Version 58 hat Google da jetzt Ernst gemacht und die Unterstützung für den Abgleich des Server-Namens mit dem CN abgeschafft. Statt dessen müssen alle Namen der Server, die sich mit diesem Zertifikat ausweisen dürfen, über die Erweiterung subjectAltName spezifiziert werden. Gibt es diese nicht, meldet Chrome lapidar: "Subject Alternative Name Missing". Und das betrifft zumindest in Chrome alle Zertifikate ohne Subject Alternative Name (SAN).

Mozilla: Gnade vor Recht

Da geht Google einen Schritt weiter als Mozilla. Die hatten in Firefox die Unterstützung für CNs bereits vor über einem Jahr bei Firefox 48 abgestellt. Allerdings haben sie diese strikte RFC-Auslegung auf neue Zertifikate beschränkt. Außerdem kommt sie nur zur Anwendung, wenn das Zertifikat von einer öffentlichen CA unterzeichnet ist, die im Firefox-Zertifikatsspeicher enthalten ist. Die CAs achten somit notgedrungen bereits seit einiger Zeit darauf, dass Zertifikate einen SAN aufweisen.

Auch Zertifikate, die entweder selbst-signiert oder von einer internen Firmen-CA ausgestellt wurden, nimmt Mozilla von der SAN-Pflicht aus. Google sieht jedoch keine solchen Ausnahmen vor. Diese Vorgehensweise ist heftig umstritten, weil die Formulierungen in den relevanten RFCs durchaus auch andere Interpretationen zulassen. So hat sich etwa im zugehörigen Chrome-Bug-Report eine rege Diskussion ergeben, ob Googles Vorgehensweise tatsächlich RFC-konform ist.

Praxis-Tipps für Admins

Doch unabhängig davon, ob Googles Interpretation richtig ist oder nicht, hat der Konzern jetzt Fakten geschaffen und Admins müssen reagieren. Denn viele interne Dienste mit selbst erstellten Zertifikaten funktionieren nicht mehr, wenn die Anwender mit Chrome darauf zugreifen. Die Administratoren müssen also jetzt möglichst schnell neue Zertifikate ausstellen und gegebenenfalls die dazu verwendete Konfiguration beziehungsweise Skripte anpassen.

Das ist leider nicht immer ganz einfach. So kann man bei OpenSSL keine SANs über die Kommandozeile oder mit den vom Benutzer abgefragten Basis-Angaben hinzufügen. Statt dessen muss man in der Konfigurationsdatei eine neue Sektion einrichten. Die hat dann beispielsweise folgenden Inhalt:

subjectAltName = @alt_names
[alt_names]
DNS.1 = www.heise.de
DNS.2 = heise.de
...

Sie muss alle validen Server-Namen enthalten. Auch ein eventuell bereits als CN angegebener Server-Name muss hier erneut auftauchen. OpenSSL zeigt die dann bei den X509-Erweiterungen an:

X509v3 extensions:
     X509v3 Subject Alternative Name: 
           DNS:www.heise.de, DNS:heise.de, ...

Das kann man in einem Skript etwa so abfragen

openssl x509 -noout -text -in $f |\
grep -A 1 "X509v3 Subject Alternative Name" |\
grep DNS | sed -e "s/\s*//"

Microsoft beschreibt die notwendigen Schritte in einem TechNet-Artike How to Request a Certificate With a Custom Subject Alternative Name. Für eine Übergangszeit bis Version 65 kann man Chrome das strikte Verhalten auch mit Hilfe dokumentierter Registry-Keys (Windows) beziehungsweise mit Preferences (Linux/Mac) des Namens EnableCommonNameFallbackForLocalAnchors abgewöhnen.


Wer Tipps zu guten Howtos hat, wie man sich diese Arbeit mit anderen Werkzeugen erleichtert, kann die gerne an mich schicken; ich trage sie dann hier nach.

1. Nachtrag:

• X.509-Erweiterungen inkl. SAN mit Keystore explorer
• Zertifikat mit SAN mit Keytool erstellen (Kommandozeilen-Tool in Java)
• Zertifikat mit SAN via Microsoft Management Console (MMC)

(ju)