Erzeugen einer RFC 2818 konformen Zertifikatanforderung für SSL Zertifikate

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.

Erstellen einer Zertifikatanforderung

Kennen Sie TameMyCerts? TameMyCerts ist ein Add-On für die Microsoft Zertifizierungsstelle (Active Directory Certificate Services). Es erweitert die Funktion der Zertifizierungsstelle und ermöglicht die Anwendung von Regelwerken, um die sichere Automatisierung von Zertifikat-Ausstellungen zu realisieren. TameMyCerts ist einzigartig im Microsoft-Ökosystem, hat sich bereits in unzähligen Unternehmen auf der ganzen Welt bewährt und steht unter einer freien Lizenz. Es kann über GitHub heruntergeladen und kostenlos verwendet werden. Professionelle Wartung wird ebenfalls angeboten.

Nachfolgend ist der Prozess beschrieben, ein zu RFC 2818 konformes Zertifikat von der Microsoft Zertifizierungsstelle zu beantragen. Hierbei wurde bewusst eine Methode gewählt, die in die einzeinen Prozess-Schritte aufgeteilt ist und somit auch für andere Systeme (beispielsweise Linux) angepasst werden kann.

Manuelle Erstellung der Zertifikatanforderung

Diese Methode bietet sich für Systeme an, die nicht Mitglied der gleichen Active Directory Gesamtstruktur sind wie die Zertifizierungsstelle. Siehe Artikel "Manuelle Beantragung eines Webserver-Zertifikats".

Erstellen der Zertifikatanforderung über die Microsoft Management Konsole (MMC)

Diese Methode bietet sich an, wenn der Webserver und die Zertifizierungsstelle Mitglied der gleichen Active Directory Gesamtstruktur sind und somit auf die im Active Directory hinterlegten Zertifikatvorlagen zurückgegriffen werden kann.

Der erste Schritt besteht darin, auf dem Zielsystem ein Schlüsselpaar und eine Zertifikatanforderung (CSR) zu erzeugen. Dieser Schritt hängt vom Ziel-Betriebssystem (Windows, Linux etc.) ab und ist vom jeweiligen Inhaber des IT-Services (dem Antragsteller, Enrollee) durchzuführen.

Für Windows wird die Zertifikate-Managementkonsole für das Computerkonto (certlm.msc) gestartet und unter Personal mit rechts auf Certificates geklickt. Im Kontextmenü wird All Tasks – Advanced Operations – Create Custom Request ausgewählt.

Hier wird nun die Zertifikatvorlage ausgewählt und anschließend auf Next geklickt.

Bevor die Zertifikatanforderung erzeugt wird, wird im nachfolgenden Dialog unter Details noch auf Properties geklickt. Bei einem Web Server Zertifikat gibt üblicherweise der Antragsteller die Identität vor, diese muss noch konfiguriert werden.

Gemäß RFC 2818 darf das Subject des Zertifikats leer sein, wenn ein Subject Alternative Name vorhanden ist. Die Subject Alternative Name Erweiterung verhält sich bei der Microsoft Zertifizierungsstelle konform zu RFC 2818 wie folgt:

• Ist das Subject leer, ist die Subject Alternative Name Erweiterung als kritisch markiert, da sie die einzige Möglichkeit zur Bestimmung der Identität enthält.
• Ist ein Common Name innerhalb des Subject vorhanden, ist die Subject Alternative Name Erweiterung als nicht kritisch markiert, um Anwendungen einen Fallback zu ermöglichen, sollten die die SAN Erweiterung nicht verstehen.

Die Erfahrung zeigt nämlich, dass es durchaus sein kann, dass ein Zertifikat von einer Anwendung verwendet werden kann, die nicht konform zum RFC 2818 programmiert wurde. Diese würde die Subject Alternative Name Erweiterung eventuell nicht kennen, und diese dann ignorieren. Ist die SAN Erweiterung als kritisch markiert, müsste die Verarbeitung des Zertifikats in diesem Fall abgebrochen werden.

Aus diesem Grund empfiehlt es sich durchaus, den Common Name weiterhin zu befüllen. Das RFC 2818 wird hierdurch nicht verletzt, da für alle konformen Anwendungen eine SAN-Erweiterung vorhanden ist.

Die Zertifikatanforderung kann nun in eine Datei abgespeichert werden. Welche Kodierung hierbei gewählt wird, ist zweitrangig.

Es wird nun ein Schlüsselpaar und eine Zertifikatanforderung erzeugt. Diese muss im nächsten Schritt an die Zertifizierungsstelle gesendet werden.

Senden der Zertifikatanforderung an die Zertifizierungsstelle

Unabhängig davon, wie die Zertifikatanforderung erzeugt wurde (Windows, Linux etc.) kann die CSR-Datei nun an die zuständige Zertifizierungsstelle gesendet werden.

Dies kann von einem beliebigen Windows-Computer in der Active Directory Gesamtstruktur erfolgen, jedoch muss der ausführende Benutzer auf der Ziel-Zertifikatvorlage das Enroll-Recht besitzen.

certreq -submit {Zertifikatanforderung}.req

Bei Zertifikatanforderungen, welche nicht mit der Microsoft MMC erzeugt wurden, ist keine Information über die Zertifikatvorlage vorhanden. Diese Information muss manuell während der Beantragung mitgegeben werden:

certreq -attrib "CertificateTemplate:{Name-der-Zertifikatvorlage}" -submit {Zertifikatanforderung}.req

Man wird nun zur Auswahl einer Ziel-Zertifizierungsstelle aufgefordert.

Anschließend wird die Zertifikatanforderung an die Zertifizierungsstelle gesendet. Ist Die Zertifikatvorlage so konfiguriert, dass die Anforderung zunächst von einem Zertifikatmanager überprüft werden muss, wird man auf diesen Umstand hingewiesen und erhält vorerst noch kein Zertifikat zurück. Wichtig ist, dass man die ausgegebene RequestId notiert, da diese zur Abholung des Zertifikats benötigt wird.

Abholen des ausgestellten Zertifikats von der Zertifizierungsstelle

Nachdem das Zertifikat durch einen Zertifikatmanager ausgestellt wurde, kann es mit folgemdem Befehl von der Zertifizierungsstelle abgeholt werden.

certreq -reqtrieve {Request-ID}

Wieder muss man die Ziel-Zertifizierungsstelle auswählen.

Anschließend kann das Zertifikat als Datei abgespeichert werden.

Verbinden des ausgestellten Zertifikats mit dem privaten Schlüsse

Dieser Schritt hängt wieder vom Ziel-System (Windows, Linux) ab. Das ausgestellte Zertifikat muss nun noch mit dem zuvor erstellen privaten Schlüssel verbunden werden, bevor es verwendet werden kann. Hierfür sind Administrator-Rechte erforderlich, wenn die Zertifikatanforderung im Maschinenkontext erstellt wurde.

certreq -accept {Zertifikat}.cer

Binden des Zertifikats an die Anwendung

Das ausgestellte und installierte Zertifikat muss nun noch an die Ziel-Anwendung gebunden werden. Dieser Schritt hängt von der jeweiligen Ziel-Anwendunge ab (beispielsweise IIS, Apache, NGINX). Für den Registrierungsdienst für Netzwerkgeräte (NDES) findet sich hier ein Beispiel.

Weiterführende Links:

• Issue 308330: Remove support for common names in certificates; only support Subject Alt Names (Chromium Projekt)
• RFC 2818 – HTTP Over TLS (Internet Engineering Task Force)