Zertifikatsketten erstellen und verwalten

Eine Root-CA ist ein selbstsigniertes Zertifikat, das als ultimativer Vertrauensanker dient. Der private Schlüssel der Root-CA muss offline aufbewahrt werden, etwa auf einem vom Netzwerk getrennten System oder in einem HSM, da eine Kompromittierung die gesamte PKI gefährdet. "openssl req -x509 -new -nodes -key root_key.pem -sha256 -days 3650 -out root_cert.pem" erstellt ein selbstsigniertes Root-Zertifikat mit einer Gültigkeit von 10 Jahren.

Intermediate-CAs werden von der Root-CA signiert und für die tägliche Zertifikatsausstellung verwendet. Erstellen Sie zunächst den Schlüssel und die CSR der Intermediate-CA: "openssl req -new -key intermediate_key.pem -out intermediate.csr". Anschließend signiert die Root-CA die CSR: "openssl x509 -req -in intermediate.csr -CA root_cert.pem -CAkey root_key.pem -CAcreateserial -days 1825 -out intermediate_cert.pem".

End-Entity-Zertifikate (Leaf-Zertifikate) werden von der Intermediate-CA für bestimmte Server oder Clients signiert. Erstellen Sie den Serverschlüssel und die CSR mit Subject Alternative Names (SANs) und signieren Sie die CSR anschließend mit der Intermediate-CA: "openssl x509 -req -in server.csr -CA intermediate_cert.pem -CAkey intermediate_key.pem -CAcreateserial -extensions v3_req -days 365 -out server_cert.pem".

Der private Schlüssel der Root-CA wird offline aufbewahrt und nur zum Signieren einer kleinen Anzahl von Zertifikaten für Intermediate-CAs verwendet. Die tägliche Zertifikatsausstellung wird von online betriebenen Intermediate-CAs durchgeführt. Wenn eine Intermediate-CA kompromittiert wird, kann sie widerrufen und ersetzt werden, ohne die Root zu kompromittieren. Der Root-Schlüssel bleibt sicher, weil er nie online zugänglich war.

Der Befehl "openssl ca" bietet einen vollständigeren CA-Workflow als "openssl x509 -req". Er verwaltet eine Zertifikatsdatenbank (index.txt), vergibt Seriennummern aus einer Serial-Datei und übernimmt die CRL-Erstellung. Dafür ist eine korrekt konfigurierte openssl.cnf-Konfigurationsdatei mit CA-spezifischen Abschnitten erforderlich, in denen die Zertifikatsrichtlinie und Pfadlängenbeschränkungen definiert werden.

Eine vollständige Zertifikatskettendatei für einen Webserver enthält das End-Entity-Zertifikat, gefolgt von den Intermediate-CA-Zertifikaten in der richtigen Reihenfolge und endet unmittelbar vor der Root-CA. Root-Zertifikate werden nicht aufgenommen, da Browser bereits vorinstallierte Root-Stores enthalten. Konkatenationsreihenfolge: "cat server_cert.pem intermediate_cert.pem > chain.pem". Eine falsche Reihenfolge führt zu TLS-Handshake-Fehlern.

"openssl verify -CAfile root_cert.pem -untrusted intermediate_cert.pem server_cert.pem" verifiziert die vollständige Kette. Das Flag "-untrusted" stellt Intermediate-Zertifikate bereit, die Teil der Kette, aber noch nicht vertrauenswürdig sind. Bei erfolgreicher Verifizierung lautet die Ausgabe "server_cert.pem: OK". Häufige Fehler weisen auf fehlende Intermediate-Zertifikate oder abgelaufene Zertifikate hin.

Zu den häufigen Problemen mit Zertifikatsketten gehören: fehlende Intermediate-Zertifikate (der Server sendet nur das Leaf-Zertifikat), eine falsche Konkatenationsreihenfolge (das Leaf-Zertifikat muss zuerst kommen), ein abgelaufenes Intermediate-Zertifikat (leicht zu übersehen, da meist nur der Ablauf des Leaf-Zertifikats überwacht wird), selbstsignierte Zertifikate, die nicht im Truststore enthalten sind, sowie eine Namensabweichung (der SAN des Zertifikats stimmt nicht mit dem Hostnamen überein). Alle diese Probleme lassen sich mit "openssl s_client -showcerts" diagnostizieren.

PKCS#12 (.pfx oder .p12) ist ein Containerformat, das den privaten Schlüssel, das End-Entity-Zertifikat und die Intermediate-Zertifikate in einer einzigen verschlüsselten Datei bündelt. Erstellen Sie ein Bundle mit "openssl pkcs12 -export -out bundle.pfx -inkey server_key.pem -in server_cert.pem -certfile intermediate_cert.pem". Dieses Format wird von IIS, .NET, Java-Keystores und vielen Unternehmensanwendungen benötigt.

PEM ist Base64-codiertes ASCII, für Menschen lesbar, unterstützt mehrere Objekte in einer Datei und wird von Apache, nginx und den OpenSSL-Tools verwendet. DER ist binär und enthält ein Objekt pro Datei; es wird von Java (für JKS-Importe), Android und einigen Unternehmenstools verwendet. PKCS#12/PFX ist ein verschlüsselter binärer Container für mehrere Objekte und wird von Windows und IIS verwendet. Prüfen Sie vor der Bereitstellung, welches Format Ihr Zielsystem erwartet.

Moderne CAs müssen alle ausgestellten Zertifikate vor der Auslieferung in Certificate-Transparency-Logs protokollieren. Bei der Erstellung einer privaten CA für den internen Gebrauch ist die Protokollierung in CT-Logs nicht erforderlich. Öffentlich erreichbare Zertifikate müssen jedoch eingebettete Signed Certificate Timestamps (SCTs) enthalten, damit Chrome ihnen vertraut. Private CAs können ihre eigenen Richtlinien ohne CT-Anforderungen verwenden.

Wenn Sie eine TLS-Zertifikatskette für einen nginx-Server zusammenstellen, in welcher Reihenfolge müssen die Zertifikate konkateniert werden?

Root-CAs sind selbstsigniert, werden offline aufbewahrt und signieren ausschließlich Intermediate-CAs. Intermediate-CAs übernehmen die tägliche Zertifikatsausstellung. Kettendateien enthalten zuerst das Leaf-Zertifikat und danach die Intermediate-Zertifikate; die Root wird weggelassen. Verifizieren Sie mit "openssl verify -CAfile root.pem -untrusted intermediate.pem leaf.pem". PKCS#12-Bundles bündeln Schlüssel und Zertifikate für Windows und Java. Eine falsche Reihenfolge der Zertifikate ist ein häufiger Grund für Fehler bei der Bereitstellung und lässt sich mit s_client -showcerts diagnostizieren.