Zertifikatskette mit SSL Labs prüfen

Zeigt der Browser beim Aufruf der Relution-Weboberfläche eine gültige Verbindung an, ist die Zertifikatskonfiguration damit noch nicht bestätigt. Desktop-Browser laden fehlende Zwischenzertifikate oft selbst nach oder haben sie bereits zwischengespeichert. Mobile Geräte, Java-basierte Clients und viele Apps tun das nicht und lehnen die Verbindung bei einer unvollständigen Kette ab.

Der kostenlose SSL Server Test von Qualys SSL Labs → prüft den Server von außen und zeigt, welche Zertifikate er tatsächlich ausliefert und ob sich daraus für die gängigen Plattformen eine gültige Kette ergibt. Die Prüfung empfiehlt sich nach jedem Zertifikatswechsel, z. B. im Anschluss an Gekauftes Zertifikat erneuern →.

Voraussetzungen #

SSL Labs prüft den Server über das Internet. Der Hostname der External URL muss dafür öffentlich im DNS auflösbar und der Server aus dem Internet auf Port 443 erreichbar sein. Für Server, die nur im internen Netz erreichbar sind, beschreibt der Abschnitt Prüfung ohne Internetzugang → eine Alternative mit OpenSSL.

Test durchführen #

1. Auf www.ssllabs.com/ssltest → wird im Feld Hostname der Hostname der External URL eingetragen, z. B. mdm.example.com – ohne https:// und ohne Pfad.
2. Soll das Ergebnis nicht in den öffentlichen Ergebnislisten der Website erscheinen, wird die Option Do not show the results on the boards aktiviert.
3. Durch Klick auf Submit wird der Test gestartet. Er dauert einige Minuten.

Ist der Hostname mehreren IP-Adressen zugeordnet (z. B. IPv4 und IPv6 oder mehrere Server hinter einem Load Balancer), prüft SSL Labs jede Adresse einzeln. In diesem Fall ist das Ergebnis jeder Adresse zu betrachten, da die Server unterschiedlich konfiguriert sein können.

SSL Labs speichert Ergebnisse eine Zeit lang zwischen. Wurde das Zertifikat seit dem letzten Test ausgetauscht, wird über den Link Clear cache auf der Ergebnisseite ein neuer Test angestoßen.

Ergebnis auswerten #

Die Gesamtnote oben auf der Ergebnisseite bewertet vor allem Protokolle und Verschlüsselungsverfahren. Für die Zertifikatskette sind zwei Bereiche im Abschnitt des Serverzertifikats maßgeblich:

• Chain issues: Die Zeile fasst das Ergebnis der Kettenprüfung zusammen. Bei einer korrekten Konfiguration lautet sie None. Incomplete bedeutet, dass ein Zwischenzertifikat fehlt, Contains anchor, dass das Root-Zertifikat mitgeliefert wird, und Incorrect order, dass die Zertifikate in der falschen Reihenfolge ausgeliefert werden.
• Certification Paths: Die Reiter Mozilla, Apple, Android, Java und Windows zeigen für den Vertrauensspeicher (Trust Store) der jeweiligen Plattform, über welchen Pfad das Serverzertifikat bis zu einem vertrauenswürdigen Root-Zertifikat zurückverfolgt wird. Wurde ein Zwischenzertifikat von mehreren Zertifizierungsstellen signiert (Cross-Signing), werden mehrere Pfade angezeigt (Path #1, Path #2 …).

Jeder Pfad listet die Zertifikate der Reihe nach auf, beginnend mit dem Serverzertifikat (1) bis zum Root-Zertifikat. Die zweite Spalte gibt an, woher das jeweilige Zertifikat stammt:

Korrekte Konfiguration #

In einer korrekten Konfiguration liefert der Server das Serverzertifikat und alle Zwischenzertifikate aus (Sent by server). Das Root-Zertifikat am Ende des Pfads stammt aus dem Vertrauensspeicher (In trust store):

Im Beispiel liefert der Server das Serverzertifikat für mdm.example.com (1) und das Zwischenzertifikat Sectigo Public Server Authentication CA DV R36 (2) aus. Das Root-Zertifikat Sectigo Public Server Authentication Root R46 (3) ist im Vertrauensspeicher enthalten. Diesen Aufbau erzeugt die Anleitung unter Gekauftes Zertifikat erneuern →.

Root-Zertifikat wird mitgeliefert #

Trägt ein Zertifikat sowohl die Angabe Sent by server (orange) als auch In trust store, liefert der Server das Root-Zertifikat mit aus. Die Zeile Chain issues lautet dann Contains anchor:

Im Beispiel steht das Root-Zertifikat USERTrust RSA Certification Authority (4) in server.pem. Clients vertrauen einem Root-Zertifikat nur, wenn es in ihrem eigenen Vertrauensspeicher liegt; die mitgelieferte Kopie wird daher nicht verwendet und vergrößert lediglich jeden Verbindungsaufbau.

Behoben wird der Fehler, indem das Root-Zertifikat aus server.pem entfernt wird:

1. Vor der Änderung wird eine Sicherung angelegt, z. B. mit cp server.pem server.pem.old.

2. Folgender Befehl listet alle Zertifikate der Datei der Reihe nach mit Inhaber (subject) und Aussteller (issuer) auf:

   openssl crl2pkcs7 -nocrl -certfile server.pem | openssl pkcs7 -print_certs -noout
   

   Das Root-Zertifikat ist der Eintrag, bei dem subject und issuer identisch sind, im Beispiel der vierte mit CN = USERTrust RSA Certification Authority.

3. In einem Texteditor wird der Block dieses Zertifikats von -----BEGIN CERTIFICATE----- bis einschließlich -----END CERTIFICATE----- gelöscht. Die Blöcke stehen in derselben Reihenfolge in der Datei wie in der Ausgabe des Befehls.

4. Der Befehl aus Schritt 2 wird wiederholt; danach darf kein Eintrag mit identischem subject und issuer mehr erscheinen.

5. Der Reverse Proxy wird neu gestartet, damit er die geänderte Datei einliest, siehe Zertifikat im Reverse Proxy einbinden →. Anschließend wird der Test über Clear cache wiederholt.

Aufbau und Prüfung der Kette beschreibt Serverzertifikat und Zwischenzertifikate zusammenführen → ausführlich.

Zwischenzertifikat fehlt #

Trägt ein Zertifikat die Angabe Extra download (orange), fehlt es in der Kette, die der Server ausliefert. Die Zeile Chain issues lautet dann Incomplete:

Im Beispiel liefert der Server das Zwischenzertifikat Sectigo Public Server Authentication Root R46 (3) nicht aus – trotz des Namens handelt es sich hier um die von AAA Certificate Services signierte Variante, also ein Zwischenzertifikat und kein Root-Zertifikat. SSL Labs hat es nachgeladen und den Pfad deshalb dennoch als Trusted bewertet. Desktop-Browser verhalten sich häufig genauso, weshalb der Fehler im Browser oft nicht auffällt. Android-Geräte, Java-basierte Clients und viele Apps laden fehlende Zwischenzertifikate dagegen nicht nach und brechen den Verbindungsaufbau mit einem Zertifikatsfehler ab.

Behoben wird der Fehler, indem das fehlende Zwischenzertifikat in server.pem aufgenommen wird:

1. Name und Fingerprint SHA256 des Eintrags mit Extra download werden notiert. Der Fingerprint ist entscheidend, da es von einem Zertifikat mehrere Varianten mit demselben Namen geben kann.

2. Das Zwischenzertifikat wird bezogen, wie in Zwischenzertifikate der Zertifizierungsstelle beziehen → beschrieben. Alternativ bietet SSL Labs über das Download-Symbol rechts neben der Pfadüberschrift (Path #3 im Beispiel) die Zertifikate des Pfads im PEM-Format an; daraus wird nur der Block des fehlenden Zertifikats übernommen. Liegt das Zertifikat nicht im PEM-Format vor, wird es wie in Zertifikat in das PEM-Format umwandeln → beschrieben umgewandelt.

3. Der Fingerprint der heruntergeladenen Datei muss mit dem notierten übereinstimmen. OpenSSL gibt ihn in Großbuchstaben mit Doppelpunkten aus, SSL Labs in Kleinbuchstaben ohne Trennzeichen:

   openssl x509 -in intermediate.pem -noout -subject -issuer -fingerprint -sha256
   

4. Nach einer Sicherung von server.pem (z. B. cp server.pem server.pem.old) wird das Zwischenzertifikat hinter dem Zertifikat eingefügt, das es ausgestellt hat. Gehört es an das Ende der Kette, genügt cat intermediate.pem >> server.pem. Dabei ist auf den Zeilenumbruch zwischen -----END CERTIFICATE----- und -----BEGIN CERTIFICATE----- zu achten.

5. Die Kette wird mit dem Prüfbefehl aus Serverzertifikat und Zwischenzertifikate zusammenführen → kontrolliert.

6. Der Reverse Proxy wird neu gestartet, siehe Zertifikat im Reverse Proxy einbinden →. Anschließend wird der Test über Clear cache wiederholt.

Gehört das fehlende Zertifikat wie im Beispiel zu einem zusätzlichen Pfad für ältere Vertrauensspeicher, während ein anderer Pfad bereits vollständig ist, liefert der Server mehrere Varianten desselben Zwischenzertifikats aus. Wie eine solche Kette aufgebaut wird, beschreibt nginx: Mehrere Zertifizierungspfade →.

Prüfung ohne Internetzugang #

Ist der Server nicht aus dem Internet erreichbar, lässt sich die ausgelieferte Kette von einem Rechner im internen Netz mit OpenSSL anzeigen. Der Hostname wird zweimal angegeben, damit der Server das passende Zertifikat auswählt (SNI):

openssl s_client -connect mdm.example.com:443 -servername mdm.example.com -showcerts </dev/null

Der Abschnitt Certificate chain der Ausgabe listet die ausgelieferten Zertifikate ab 0 durchnummeriert mit Inhaber (s:) und Aussteller (i:) auf:

Certificate chain
 0 s:CN = mdm.example.com
   i:C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36
 1 s:C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36
   i:C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication Root R46

Die Kette ist korrekt, wenn an Position 0 das Serverzertifikat steht und der Aussteller (i:) jedes Eintrags dem Inhaber (s:) des nachfolgenden entspricht. Der Aussteller des letzten Eintrags ist das Root-Zertifikat, das selbst nicht in der Liste steht. Hat der letzte Eintrag identischen Inhaber und Aussteller, wird das Root-Zertifikat mitgeliefert.

Am Ende der Ausgabe meldet die Zeile Verify return code: 0 (ok) eine gültige Kette. Die Codes 20 (unable to get local issuer certificate) und 21 (unable to verify the first certificate) weisen auf ein fehlendes Zwischenzertifikat hin. Sie treten ebenfalls auf, wenn das Root-Zertifikat im Vertrauensspeicher des prüfenden Rechners fehlt, z. B. bei Zertifikaten einer eigenen Zertifizierungsstelle.