nginx: Mehrere Zertifizierungspfade

Zertifizierungsstellen lassen neue Root-Zertifikate zusätzlich von älteren, weit verbreiteten Root-Zertifikaten signieren (Cross-Signing). Für ein Serverzertifikat gibt es dadurch mehrere Zertifizierungspfade: Clients, deren Vertrauensspeicher das neue Root-Zertifikat bereits enthält, verwenden den kurzen Pfad; ältere Clients, z. B. ältere Android-Versionen oder Java-Laufzeitumgebungen, verwenden einen Pfad über ein älteres Root-Zertifikat.

nginx liefert je Schlüssel genau eine Zertifikatsdatei aus. Mehrere Pfade entstehen, indem diese Datei (server.pem) alle Zwischenzertifikate enthält, die für die gewünschten Pfade benötigt werden. Jeder Client wählt daraus den Pfad, der zu seinem Vertrauensspeicher passt.

Diese Anleitung setzt voraus, dass Serverzertifikat und Schlüssel wie in Gekauftes Zertifikat erneuern → vorbereitet wurden. Sie erweitert die dort erstellte server.pem um zusätzliche Zwischenzertifikate.

Beispiel: Sectigo mit drei Pfaden #

Das folgende Ergebnis von SSL Labs → zeigt einen Server mit einem Zertifikat von Sectigo, für das drei Zertifizierungspfade existieren:

Das Serverzertifikat (1) wurde von Sectigo Public Server Authentication CA DV R36 ausgestellt. Darüber verzweigen die Pfade:

Das Root-Zertifikat Sectigo Public Server Authentication Root R46 ist vergleichsweise neu und fehlt in älteren Vertrauensspeichern. Für diese Clients gibt es die Pfade #2 und #3, in denen R46 von einem älteren Root-Zertifikat signiert ist.

Ein Name, drei Zertifikate #

Sectigo Public Server Authentication Root R46 erscheint im Beispiel dreimal. Trotz des Namens ist es nur in Pfad #1 ein Root-Zertifikat. In den Pfaden #2 und #3 handelt es sich um eigenständige Zertifikate mit demselben Namen und demselben Schlüssel, die von einer anderen Zertifizierungsstelle ausgestellt wurden. Sie sind nicht selbstsigniert und damit Zwischenzertifikate:

Da der Name gleich ist, lassen sich die Varianten nur über Aussteller und Fingerprint unterscheiden. Der Pin (Pin SHA256) ist bei allen drei gleich, da er sich aus dem gemeinsamen Schlüssel ergibt.

Fehler im Beispiel #

Der Server im Beispiel ist nicht korrekt konfiguriert. In Pfad #2 liefert er das Root-Zertifikat USERTrust RSA Certification Authority mit aus (Sent by server in Orange), in Pfad #3 fehlt die von AAA Certificate Services signierte Variante von R46 (Extra download). Beide Fehler und ihre Behebung beschreibt Zertifikatskette mit SSL Labs prüfen →. Die folgenden Abschnitte zeigen die korrekte Kette für alle drei Pfade.

Zertifikate beschaffen und identifizieren #

Für die drei Pfade werden neben dem Serverzertifikat folgende Zwischenzertifikate benötigt:

• Sectigo Public Server Authentication CA DV R36
• Sectigo Public Server Authentication Root R46, ausgestellt von USERTrust RSA Certification Authority
• Sectigo Public Server Authentication Root R46, ausgestellt von AAA Certificate Services

Die cross-signierten Varianten stellt die Zertifizierungsstelle auf ihrer Website bereit. Alternativ bietet SSL Labs über das Download-Symbol rechts neben jeder Pfadüberschrift die Zertifikate des jeweiligen Pfads im PEM-Format an. Wie Zwischenzertifikate allgemein bezogen und in das PEM-Format umgewandelt werden, beschreibt Zwischenzertifikate der Zertifizierungsstelle beziehen →.

Da die Dateinamen der Zertifizierungsstellen nicht immer erkennen lassen, um welche Variante es sich handelt, wird jede Datei vor der Verwendung geprüft:

openssl x509 -in sectigo-r46-usertrust.pem -noout -subject -issuer -fingerprint -sha256

Die Zeile issuer nennt den Aussteller, die Zeile sha256 Fingerprint den Fingerprint, der mit der Tabelle oben bzw. mit der Anzeige in SSL Labs übereinstimmen muss. OpenSSL gibt ihn in Großbuchstaben mit Doppelpunkten aus, SSL Labs in Kleinbuchstaben ohne Trennzeichen. Sind subject und issuer identisch, handelt es sich um das Root-Zertifikat; es wird nicht benötigt.

Kette zusammenstellen #

server.pem beginnt mit dem Serverzertifikat, gefolgt von dem Zwischenzertifikat, das es ausgestellt hat. Danach folgen die cross-signierten Varianten. Root-Zertifikate werden nicht aufgenommen – weder das selbstsignierte R46 noch USERTrust RSA Certification Authority oder AAA Certificate Services. Clients, die R46 als Root-Zertifikat kennen, beenden den Pfad bereits nach Sectigo Public Server Authentication CA DV R36.

Nach einer Sicherung der bisherigen Datei (z. B. cp server.pem server.pem.old) wird die Kette zusammengeführt:

cat server-cert.pem sectigo-dv-r36.pem sectigo-r46-usertrust.pem sectigo-r46-aaa.pem > server.pem

Die Prüfung der Kette zeigt anschließend vier Einträge:

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

subject=CN = mdm.example.com
issuer=C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36

subject=C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36
issuer=C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication Root R46

subject=C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication Root R46
issuer=C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority

subject=C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication Root R46
issuer=C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services

Kein Eintrag hat identischen subject und issuer; die Datei enthält also kein Root-Zertifikat. Die beiden letzten Einträge tragen denselben subject, unterscheiden sich aber im issuer.

Jedes zusätzliche Zertifikat vergrößert jeden Verbindungsaufbau um etwa 1,5 bis 2 KB. Ein zusätzlicher Pfad wird daher nur aufgenommen, wenn Geräte oder Clients im Einsatz sind, deren Vertrauensspeicher das neuere Root-Zertifikat nicht enthält.

nginx konfigurieren #

An der nginx-Konfiguration ändert sich nichts: ssl_certificate verweist weiterhin auf server.pem, ssl_certificate_key auf server.key. nginx liefert alle Zertifikate der Datei in der Reihenfolge aus, in der sie dort stehen.

server {
    listen 0.0.0.0:443 ssl default_server;
    …

    ssl_certificate      /etc/nginx/server.pem;
    ssl_certificate_key  /etc/nginx/server.key;
    …
}

Zwei Missverständnisse liegen nahe:

• Mehrere ssl_certificate-Einträge sind in nginx für Zertifikate mit unterschiedlichen Schlüsseltypen vorgesehen (z. B. RSA und ECDSA), nicht für alternative Ketten desselben Zertifikats.
• ssl_trusted_certificate dient der Prüfung von OCSP-Antworten und Client-Zertifikaten. Zertifikate aus dieser Datei werden nicht an Clients ausgeliefert und ergänzen die Kette daher nicht.

Damit nginx die geänderte Datei einliest, wird es neu gestartet:

• Docker-Installation: nginx-Container neu starten →
• Native Installation unter Windows oder Linux: Native Installation: Zertifikat erneuern →

Ergebnis prüfen #

Abschließend wird die Konfiguration mit SSL Labs geprüft, wie in Zertifikatskette mit SSL Labs prüfen → beschrieben. Nach einem Zertifikatswechsel wird dafür über Clear cache ein neuer Test gestartet.

Die Konfiguration ist korrekt, wenn in den Reitern Mozilla, Apple, Android, Java und Windows in jedem Pfad alle Zwischenzertifikate die Angabe Sent by server tragen und das jeweils letzte Zertifikat ausschließlich In trust store. Die Angabe Extra download darf in keinem Pfad erscheinen, und kein Zertifikat mit dem Zusatz Self-signed darf zugleich Sent by server tragen.