Google ist mit dem Chromium Projekt und darauf basierenden Produkten wie Google Chrome und Microsoft Edge dazu übergegangen, das im Jahr 2000 verabschiedete RFC 2818 zu erzwingen und Zertifikaten nicht mehr zu vertrauen, welche das RFC nicht mehr erfüllen.
Für uns ist folgender Satz von großer Brisanz:
If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead
https://tools.ietf.org/html/rfc2818
Bitte beachten, dass die Aussagen betreffend der Abbildung der Identität innerhalb eines Zertifikats in diesem Artikel ausschließlich auf den Anwendungsfall HTTP über SSL (HTTPS) abzielen.
Das RFC fordert also, dass die Identität einer Webseite nicht mehr aus dem "Common Name" Feld innerhalb des Subject gebildet werden soll, sondern aus einem oder mehreren dNSName Einträgen innerhalb der Subject Alternative Name (SAN) Erweiterung innerhalb des Zertifikats. Somit ist ein Zertifikat ohne SAN Erweiterung nicht RFC-konform und wird von diesen Browsern nicht mehr akzeptiert.
Leider ist es mit vielen Anwendungen – insbesondere älteren Appliances – oft nicht möglich, einen Zertifikatantrag zu erstellen, der einen Subject Alternative Name enthält.
Google Chrome wird die Verbindung mit dem Fehlercode ERR_CERT_COMMON_NAME_INVALID verweigern. Da Microsoft Edge mittlerweile auch auf Google Chrome basiert, wird die Fehlermeldung dort identisch ausfallen.
Mozilla Firefox wird auf gleiche Weise die Verbindung verweigern. Der Fehlercode lautet hier: SSL_ERROR_BAD_CERT_DOMAIN.
Zwar gibt es verschiedene Wege, einen Subject Alternative Name auch nachträglich hinzuzufügen, bevor das Zertifikat ausgestellt wird. Einige davon sind jedoch äußert unsicher, und alle haben gemeinsam, dass sie händisch durchgeführt müssen und fehleranfällig sind.
Damit ist jetzt Schluss! Das TameMyCerts Policy Modul für die Microsoft Active Directory Certificate Services ist in der Lage, DNS-Namen im Subject Distinguished Name zu erkennen und automatisch in einen Subject Alternative Name zu übertragen.
TameMyCerts hat sich mittlerweile im produktiven Betrieb bei zahlreichen namhaften Unternehmen und Behörden bewährt. Das Beste ist: TameMyCerts ist quelloffen (Open Source) und kann kostenfrei verwendet werden.
Bei ernsthaftem Interesse, TameMyCerts produktiv einzusetzen kann ein Wartungsvertrag abgeschlossen werden. Der Abschluss eines Wartungsvertrags stellt sicher, dass Sie qualifizierte Unterstützung erhalten und das Modul langfristig weiterentwickelt werden kann.
Die Umsetzung
Um eine Zertifikatvorlage durch TameMyCerts zu verwalten, wird eine Konfigurationsdatei benötigt. Während der Installation des Moduls auf der Zertifizierungsstelle wird ein Verzeichnis angegeben, in welchem die Konfigurationsdateien gespeichert werden.
Die Datei muss nach der Zertifikatvorlage benannt zu werden. Wichtig hierbei ist, dass damit der Name des LDAP-Objektes gemeint ist, und nicht der Anzeigename. Den Objektnamen kann man über die Verwaltungskonsole für Zertifikatvorlagen herausfinden, indem man mit rechts auf die Zertifikatvorlage klickt und die Option "Change Names…" wählt.
Angenommen, der Objektname unserer Zertifikatvorlage ist "ADCSLaborWebserver", nennen wir wir die Konfigurationsdatei entsprechend"ADCSLaborWebServer.xml".
Jede Konfigurationsdatei beginnt mit einem Knoten namens CertificateRequestPolicy, in welchem die Konfigurations-Direktiven eingetragen werden.
Da es sich bei unserem Use Case um eine Offline-Zertifikatvorlage handelt, müssen wir zunächst eine Regel für den Inhalt des Zertifikatantrags definieren. Das mindeste, was wir benötigen, ist eine Regel für den Subject Distinguished Name. Dies wird durch eine SubjectRule innerhalb des Bereichs Subject erreicht.
Ein Zertifikatantrag wird in der Regel einen "Common Name" beinhalten. TameMyCerts arbeitet nach dem Prinzip "was nicht definiert ist, ist verboten". Zertifikatanträge, welche nicht definierten Inhalt aufweisen, werden abgelehnt.
Daher muss eine entsprechende Regel für das commonName Feld erstellt werden. Durch setzen des Mandatory Schalters wird sichergestellt, dass Zertifikatanträge, die keinen "Common Name" beinhalten, ebenfalls automatisch abgelehnt werden.
In die Liste der Patterns wird ein Pattern-Knoten angelegt und eine Expression definiert. In diesem Fall geben wir durch einen regulären Ausdruck an, dass nur DNS-Namen innerhalb der Domain "adcslabor.de akzeptiert werden. Weicht der "Common Name" also von dieser Regel ab, wird der eingehende Zertifikatantrag automatisch abgelehnt.
Optional können weitere Regeln definiert werden. Typischerweise würde man noch folgende Dinge mit aufnehmen:
- Zusätzliche Felder (Relative Distinguished Names, RDNs) im Subject Distinguished Name (DN) wie organizationName, organizationalUnitName usw… Für eine Liste möglicher RDNs siehe auch Artikel "Erlaubte Relative Distinguished Names (RDNs) im Subject Distinguished Name (DN) ausgestellter Zertifikate".
- Eine Regel für Subject Alternative Names (SAN) im Zertifikatantrag. Schließlich könnte der Zertifikatantrag bereits einen solchen enthalten.
Letzendlich wird noch die SupplementDnsNames Direktive gesetzt. Durch diese wird TameMyCerts angewiesen im "Common Name" gefundene DNS-Namen in den Subject Alternative Name (SAN) zu übernehmen.
Wird nun ein Zertifikat für die eingerichtete Zertifikatvorlage beantragt, stellt TameMyCerts automatisch sicher, dass das ausgestellte Zertifikat einen gültigen Subject Alternative Name beinhaltet.
Deutsch 
English