Chrome beendet die Kontrolle des Common Name im Zertifikat

17.05.2017 | Petra Alm

Mit der Version 58 hört Google Chrome auf, den Common Name von SSL-Zertifikaten zu überprüfen. Was bedeutet es? Kunden von SSLmarket und große Zertifizierungsstellen brauchen sich überhaupt nicht zu beunruhigen – es handelt sich nur um das Ergebnis mehrjähriger Bemühungen, in den Zertifikaten nur die DNS-Namen zu nutzen.

Was wird in Chrome 58 anders?

In der neuen Version ändert Chrome die Vorgehensweise bei der Überprüfung von den in dem SSL/TLS Zertifikat angegebenen Domains. Nachdem die Adresse der mit dem SSL-Zertifikat abgesicherten Domain in die Adresszeile eingegeben wird, führt der Browser den sog. Handshake durch, bei welchem er von dem Server das Zertifikat mit dem öffentlichen Schlüssel herunterlädt und Details der abgesicherten Kommunikation „abspricht“. Während die Verbindung mit dem abgesicherten Server aufgebaut wird, überprüft der Browser, für welche Domain das Zertifikat ausgestellt ist und natürlich muss es zu einer Übereinstimmung kommen, sonst wird eine Sicherheitswarnung eingeblendet.

Von nun an wird Chrome also nicht mehr den Common Name des Zertifikats (d.h. die Hauptdomain), sondern die Werte in dem Feld alternativer Antragstellername (subjectAltName) überprüfen. In diesem sind alle DNS-Namen aufgeführt, für welche das Zertifikat gültig ist. Falls sich auf der Domain ein für eine andere Domain ausgestelltes Zertifikat befindet, oder falls es den betreffenden Domainnamen nicht enthält, wird die Verbindung mit einer Fehlermeldung unterbrochen, der Nutzer auf ein Sicherheitsrisiko hingewiesen und dazu aufgefordert, das Web zu verlassen.

Mit dieser Änderung ist eine Interessantheit verbunden – das Bestreben, die Kontrolle von dem Common Name des Zertifikats zu verlassen, ist unglaubliche 17 Jahre alt. Diese Absicht finden wir in RFC 2818 von Mai 2000 mit dem Namen HTTP Over TLS, was tatsächlich ein das HTTPS-Protokoll definierender Standard ist. Eigentlich handelt es sich also vonseiten Chrome um keinen Umsturz, aber auch trotzdem kann die Verwirklichung der Idee aus dem Jahre 2000 einige Administratoren und Firmen verärgern.

Kunden von SSLmarket werden nicht betroffen, self-signed Zertifikate sollten jedoch überprüft werden

Unsere Kunden können sich darauf verlassen, dass sie die Änderung nicht beeinflussen wird. Alle von den Zertifizierungsstellen Symantec, Thawte, GeoTrust und RapidSSL ausgestellten Zertifikate enthalten den Common Name auch als den DNS Namen und sind mit Chrome 100% kompatibel.

Der Common Name wird in die Liste von DNS-Namen (subjectAltName) automatisch hinzugefügt (Baseline requirements des CAB Forums erlegen dies den Zertifizierungsstellen seit dem Jahre 2012 auf) und die CAs der Familie Symantec ergänzen die Domains der 2. Ebene und Domains der 3. Ebene mit WWW um die zweite Form kostenlos. Damit ermöglichen sie dem Zertifikatsinhaber, das Zertifikat auf beide Varianten (sowohl auf die mit als auch auf die ohne WWW) einzusetzen. Die Mehrheit der Zertifikate kann gegen eine Gebühr auch um weitere Namen ergänzt werden. Die DNS-Namen, um die Zertifikat erweitert werden kann, werden SAN genannt und die Zertifikate, die diese mehrfache Anwendung unterstützen, heißen SAN-Zertifikate (Microsoft nennt sie UCC).

Probleme erwarten jedoch Inhaber der für interne Zwecke ausgestellten Zertifikate – es handelt sich zum Beispiel um selfsigned Zertifikate von Servern, Diensten oder Intranets. Die Änderung kann auch Server der Plattform Microsoft treffen, denn die Utility Makecert.exe (mit der die selfsigned Zertifikate erstellt werden können) unterstützt die SAN-Namen nicht.

Es ist nebensächlich, warum das betroffene Zertifikat genutzt wird. Die Ursachen (z.B. interne Domains wie .local, für die kein vertrauenswürdiges Zertifikat ausgestellt werden kann, vs. Versäumnis des Administrators) sind für Chrome nicht relevant. Falls das Zertifikat den Common Name als DNS Namen in dem Feld alternativer Antragstellername nicht enthält, muss es neu erstellt werden und der Name muss als SAN ergänzt werden. Die optimale Lösung wäre jedoch die Domain mit einem vertrauenswürdigen Zertifikat von dem Angebot von SSLmarket abzusichern.

Die Neuheit kann umgangen werden

Falls in Ihrer Infrastruktur die behandelte Neuheit von Chrome ein Problem darstellt, können Sie sie zeitweilig ausschalten. In Windows Registrierungsdatenbanken suchen Sie den Zweig HKEY_LOCAL_MACHINESoftwarePoliciesGoogleChrome aus und in diesem erstellen Sie den Wert REG_DWORD mit dem Namen EnableCommonNameFallbackForLocalAnchors und dem Wert 1.

Diese Maßnahme kann die Situation jedoch nur bis die Version 65 lösen, in der Google die Option von Chrome entfernen wird. Sie sollten auf sie deshalb nur in kritischen Fällen zugreifen.