SAN-Zertifikat mit Java-Keytool erstellen

Seit 2017 gilt Google Chrome als Vorreiter für die SAN-Pflicht in SSL-Zertifikaten. Sobald das Zertifikat keinen SAN-Eintrag vorweist, spuckt beispielsweise Google Chrome eine Fehlermeldung aus, dass die Seite nicht vertrauenswürdig sei:

NET::ERR_CERT_COMMON_NAME_INVALID

Hintergründe von SAN-Zertifikaten

Historisch gesehen ist es ein Designproblem des X509 Standards gewesen, dass der CN gleichzeitig als Domänenname genutzt worden ist. Daher wurde bereits im Jahre 2000 mit der Veröffentlichung von SSL davon abgeraten (RFC2818), den CN als Faktor für die Validierung des Hostnames zu verwenden. Stattdessen sollte man nun die Erweiterung des X509 Standards zur Validierung verwenden, nämlich "subjectAltName". Google Chrome macht den ersten Schritt und "zwingt" die Administratoren und Betreiber von Webseiten RFC-konform zu handeln. Schließlich wurde der Standard schon vor ungefähr 20 Jahren festgelegt!

Sprich: Es wird nicht mehr wie bisher der Common Name (CN) von
Zertifikaten überprüft, sondern der Browser schaut direkt zur Validierung des Hostnames auf die SAN-Einträge.
Manche Browser validieren dennoch aus Kompatibilitätsgründen über den CN, wenn sie keinen SAN-Eintrag im Zertifikat finden. Generell gilt dieses Verfahren für nicht mehr aktuell und empfehlenswert und es ist eine Frage der Zeit bis die anderen Anbieter mitziehen.

Vorteile von SAN-Zertifikaten

Bevor ich näher auf den praktischen Teil eingehe, erläutere ich kurz den wesentlichen Vorteil von einem SAN-Zertifikat zu herkömmlichen Zertifikaten ohne die Erweiterung "subjectAltName".

Der wesentliche Vorteil von einem SAN-Zertifikat ist es, dass es mehrere Hostnames (Domains) beinhalten kann, statt wie zuvor nur einen. Es ist die Rede, dass je nach Provider mit einem Zertifikat 100-200 Domains abgedeckt werden können (nicht empfehlenswert, aber realisierbar).
Einige von euch könnten nun eventuell den Gedanken hegen, dass man diese auch schon mit einem Wildcard-Zertifikat umsetzen kann.
Allerdings existieren zwei deutliche Unterschiede zwischen einem Wildcard-Zertifikat und einem SAN-Zertifikat:

Erstens: Wildcard-Zertifikate sind gebunden auf eine Domänenebene und daher eingeschränkt beispielsweise "*.nocksoft.de". Ich könnte zwar mit diesem Zertifikat Hostnames wie "test.nocksoft.de", "nocksoft.de" oder "prod.nocksoft.de" abdecken, aber niemals "test.nocksoft.com", "nocksoft.com" oder "nocksoft1.de".
SAN-Zertifikate geben uns hierfür mehr Freiraum, sodass alle oben genannten Beispieldomains mit dieser abgedeckt werden können.

Zweitens: Während SAN-Zertifikate eindeutig auf einen Domainnamen zeigen wie beispielsweise "test.nocksoft.de", könnte ein Wildcard-Zertifikat unzählige Domains bzw. Subdomains beinhalten und für jegliche Services genutzt werden. Ein Angreifer könnte ganz leicht bei Kompromittierung der Domäne "nocksoft.de" Subdomains erstellen und diese mithilfe des Wildcard-Zertifikates für valide erklären und Phishing betreiben. Ganz zu Schweigen von den Kommunikationen, die mithilfe des kompromittierten Private-Keys entschlüsselt werden können.

SAN-Zertifikate in der Praxis

Rafael hatte euch bereits hier einen Einblick gegeben, wie man mithilfe eines Zertifikates ein Web im Tomcat auf HTTPS umstellt. Da die Vorgehensweise bis auf die Erstellung des Zertifikates identisch ist, werde ich nur auf die Erstellung des Keystores und Zertifikates eingehen. Die Einbindung im Tomcat könnt ihr aus dem verlinkten Beitrag entnehmen.

Erstellung von SAN-Zertifikaten mithilfe vom Java-Keytool

Zunächst führen wir folgenden Befehl aus, um ein Keystore zu erstellen:

keytool -genkey -alias nocksoft.de -keyalg RSA -keystore nocksoft.jks -keysize 2048

Dieser Befehl erstellt ein private/public Key-Paar mit einer Länge von 2048 Bit (RSA). Der private Schlüssel ist im Keystore unter dem Alias 'nocksoft.de' abrufbar. Gespeichert ist die "nocksoft.jks" Datei im Ordnerverzeichnis des Keytools.
Nach Ausführen des oben genannten Befehls wird man nach einem Passwort gefragt, damit der private Schlüssel sicher im Keystore gespeichert ist.
Anschließend wird noch nach den (persönlichen) Informationen zur Identifikation des Inhabers gefragt:

Als nächstes wird mithilfe des erzeugten Schlüsselpaares ein "Certificate Signing Request" (CSR) erstellt. Dies geschieht wie folgt:

keytool -certreq -file nocksoft.csr -keystore nocksoft.jks -alias nocksoft.de -ext SAN=dns:nocksoft.de,dns:www.nocksoft.de,dns:nocksoft.com,dns:www.nocksoft.com,ip:217.160.0.90

Mit "-ext SAN..." definieren wir den Inhalt des SAN-Eintrags, also die Domains, aber auch optional eine IP, die das Zertifikat enthalten soll. Der CSR, welcher wichtige Informationen enthält wie z.B. den Public Key, muss nun von einer Zertifizierungsstelle (Certificate authority) unterschrieben werden. Es existieren zahlreiche Anbieter wie GlobalSign oder DigiCert hierfür. Natürlich prüft die CA vorher durch eine Mail oder DNS-Request oder sonstiges, ob die Domain wirklich euch gehört. Alternativ kann für interne Zwecke der CSR bei der Active Directory Zertifizierungsstelle eingereicht werden.
Nach Hochladen des CSR bekommt ihr nun das gewünschte Zertifikat.

Dieses (nocksoft.cer) müssen wir nun in unser Keystore (nocksoft.jks) unter dem selben Alias des private Keys (bei mir nocksoft.de) importieren:

keytool -import -trustcacerts -alias nocksoft.de -file "nocksoft.cer" -keystore "nocksoft.jks"

Import von Intermediate CAs

Gegebenenfalls muss zusätzlich noch eine Zwischen-CA importiert werden, welche beim jeweiligen Anbieter frei heruntergeladen werden kann. Die gängigen Root-Zertifikate der CAs sind in der Regel im Java Keystore bekannt. Überprüfen könnt ihr das beim Betrachten eures Zertifikates:

Voila! Nun ist euer Keystore bereit für die Anbindung zum Tomcat.

Keystore für andere Webserver konvertieren

Falls das Zertifikat für andere Systeme verwendet werden soll wie Microsoft IIS oder Microsoft Azure könnt ihr dieses problemlos z.B. in das p.12 Format (pfx) konvertieren, womit die beiden Systeme arbeiten können:

keytool -importkeystore -srckeystore "nocksoft.jks" -destkeystore "nocksoft.p12" -deststoretype PKCS12

Tipp: Zum Auflisten aller Einträge in eurem Keystore könnt ihr folgenden Befehl verwenden:

keytool -list -keystore "nocksoft.jks"

Weiterführende Links
https://www.globalsign.com/de-de/blog/was-ist-ein-certificate-signing-request

Quellen
https://www.digicert.com/subject-alternative-name.htm
https://unmitigatedrisk.com/?p=381