PEM-Bundle-Merger
Mehrere pem-Zertifikate zu einem Bundle zusammenfuehren
PEM Inputs
Paste PEM blocks to merge into a bundle
Der PEM Bundle Merger kombiniert mehrere einzelne PEM-Zertifikate zu einer korrekt geordneten Zertifikatskettendatei und bestimmt automatisch die richtige Reihenfolge vom End-Entity- bis zum Root-Zertifikat -- entscheidend für die TLS-Konfiguration auf Webservern wie nginx, Apache und HAProxy. Fügen Sie Ihre Zertifikate in beliebiger Reihenfolge ein und erhalten Sie eine korrekt zusammengestellte Kette, die für die Bereitstellung bereit ist.
Zusammenstellung von Zertifikatsketten verstehen
Jede TLS-Verbindung erfordert, dass der Server eine Zertifikatskette präsentiert, die es dem Client ermöglicht, einen Vertrauenspfad vom Leaf-Zertifikat des Servers zu einer Root-CA aufzubauen, der er vertraut. Wenn die Kette unvollständig ist oder in der falschen Reihenfolge vorliegt, lehnen Clients die Verbindung mit Fehlern wie "unable to verify the first certificate" oder "certificate chain too long" ab. Diese Kette korrekt aufzubauen ist eine der häufigsten Aufgaben in der TLS-Serveradministration, und es ist überraschend leicht, dabei Fehler zu machen.
Die Herausforderung besteht darin, dass Zertifizierungsstellen Zertifikate oft in Einzelteilen liefern. Sie erhalten möglicherweise Ihr Leaf-Zertifikat in einer E-Mail, das Zwischenzertifikat in einer anderen und das Root-Zertifikat von einer separaten Download-Seite. Oder Ihr Automatisierungstool generiert einen CSR und erhält nur das Leaf-Zertifikat zurück, sodass Sie das korrekte Zwischenzertifikat selbst finden müssen. Das Ergebnis ist eine Sammlung einzelner PEM-Dateien, die in der richtigen Reihenfolge zusammengesetzt werden müssen, bevor Ihr Webserver sie akzeptiert.
Dieser Merger automatisiert diese Zusammenstellung. Fügen Sie alle Ihre Zertifikate in beliebiger Reihenfolge ein, und das Tool analysiert die Subject- und Issuer-Felder jedes Zertifikats, um herauszufinden, welches das Leaf ist, welche Zwischenzertifikate sind und welches das Root ist. Anschließend werden sie in der korrekten Reihenfolge ausgegeben: Leaf zuerst, gefolgt von Zwischenzertifikaten, mit dem Root optional am Ende. Die Ausgabe ist eine einzelne PEM-Datei, die Sie direkt in Ihre nginx- oder Apache-Konfiguration einsetzen können.
So führen Sie PEM-Zertifikate zu einer Kette zusammen
- Fügen Sie Ihre einzelnen PEM-Zertifikate ein (in beliebiger Reihenfolge)
- Das Tool analysiert Subject- und Issuer-Felder, um die korrekte Kettenreihenfolge zu bestimmen
- Überprüfen Sie die automatisch geordnete Kette und eventuelle Validierungswarnungen
- Kopieren oder laden Sie das zusammengeführte PEM-Bundle herunter
Beispiel: Aufbau einer Zertifikatskette
Eingabe -- drei Zertifikate in falscher Reihenfolge eingefügt:
Certificate 1: CN=R3, O=Let's Encrypt (intermediate)
Certificate 2: CN=ISRG Root X1 (root)
Certificate 3: CN=www.example.com (leaf)
Ausgabe -- korrekt geordnete Kette:
| Position | Subject | Issuer | Rolle |
|---|---|---|---|
| 1 | CN=www.example.com | CN=R3, O=Let's Encrypt | Leaf (End-Entity) |
| 2 | CN=R3, O=Let's Encrypt | CN=ISRG Root X1 | Zwischenzertifikat |
| 3 | CN=ISRG Root X1 | CN=ISRG Root X1 | Root (optional) |
Die zusammengeführte Ausgabe ist eine einzelne PEM-Datei mit Zertifikaten in der korrekten Reihenfolge, bereit für die Serverbereitstellung.
Wann sollte man dieses Tool verwenden
- Zusammenstellung CA-gelieferter Zertifikate -- viele Zertifizierungsstellen liefern Leaf- und Zwischenzertifikate als separate Dateien, die Sie in der richtigen Reihenfolge verketten müssen
- Reparatur defekter Ketten -- eine Zertifikatskette neu aufbauen, die Fehler wie "unable to verify the first certificate" oder "incomplete chain" verursacht
- Vorbereitung für die Serverbereitstellung -- eine korrekt formatierte Kettendatei für nginx
ssl_certificate, ApacheSSLCertificateChainFileoder HAProxy-PEM-Bundles erstellen - Plattformübergreifender Kettenaufbau -- Zertifikate aus verschiedenen Quellen (heruntergeladenes Root, ausgestelltes Zwischenzertifikat, generiertes Leaf) zu einer einheitlichen Kette kombinieren
- Zertifikatserneuerung -- ein neues Leaf-Zertifikat nach der Erneuerung mit bestehenden Zwischenzertifikaten zusammenführen
- Multi-Intermediate-Ketten -- Ketten mit zwei oder mehr Zwischenzertifikaten (üblich bei einigen kommerziellen CAs) in der korrekten Reihenfolge zusammenstellen
Wie die Zertifikatskettenreihenfolge funktioniert
TLS erfordert, dass Zertifikate während des Handshakes in einer bestimmten Reihenfolge präsentiert werden. Der Server sendet seine Kette an den Client, und der Client muss in der Lage sein, einen Vertrauenspfad vom Leaf zu einer Root-CA aufzubauen, der er vertraut.
Kettenvalidierungslogik
Der Merger verifiziert die Kette, indem er das Issuer-Feld jedes Zertifikats mit dem Subject-Feld des nächsten Zertifikats abgleicht:
Leaf: Subject=CN=www.example.com
Issuer=CN=R3, O=Let's Encrypt
| (Issuer stimmt mit nächstem Subject überein)
Intermediate: Subject=CN=R3, O=Let's Encrypt
Issuer=CN=ISRG Root X1
| (Issuer stimmt mit nächstem Subject überein)
Root: Subject=CN=ISRG Root X1
Issuer=CN=ISRG Root X1 (selbstsigniert)
Häufig erkannte Kettenfehler
Der Merger warnt vor Problemen, die er während der Zusammenstellung findet:
- Fehlendes Zwischenzertifikat -- es besteht eine Lücke, bei der kein Subject eines Zertifikats mit dem Issuer des vorherigen Zertifikats übereinstimmt
- Doppelte Zertifikate -- dasselbe Zertifikat erscheint mehr als einmal in der Eingabe
- Zyklus erkannt -- Zertifikate bilden eine Schleife statt einer linearen Kette
- Mehrere Leaf-Zertifikate -- mehr als ein Zertifikat ist nicht der Issuer eines anderen Zertifikats in der Eingabe
- Unnötiges Root -- das selbstsignierte Root-CA-Zertifikat ist enthalten; die meisten Serverkonfigurationen sollten es weglassen
Serverkonfiguration für zusammengeführte Ketten
Verwenden Sie nach dem Zusammenführen die Kettendatei in Ihrer Serverkonfiguration:
nginx:
ssl_certificate /etc/ssl/certs/example.com-chain.pem;
ssl_certificate_key /etc/ssl/private/example.com.key;
Apache:
SSLCertificateFile /etc/ssl/certs/example.com.crt
SSLCertificateChainFile /etc/ssl/certs/example.com-chain.pem
HAProxy erwartet den privaten Schlüssel, der in einer einzelnen Datei an die Kette angehängt wird.
Kettenzusammenstellung in der Praxis
Der häufigste Fehler beim Aufbau von Ketten ist die Verwechslung des richtigen Zwischenzertifikats. Große CAs wie DigiCert und Sectigo pflegen mehrere Zwischenzertifikate, und die Verwendung des falschen erzeugt eine Kette, die vollständig aussieht, aber die Validierung nicht besteht, weil die Subject/Issuer-Verknüpfung an einer Stelle unterbrochen ist. Wenn Sie Ihr Zertifikat von der CA erhalten, laden Sie die Zwischenzertifikate immer von derselben Bestellung oder derselben Seite herunter -- verwenden Sie keine Zwischenzertifikate aus einer früheren Zertifikatsbestellung wieder, da die CA ihre Zwischenzertifikate seitdem möglicherweise rotiert hat.
Ein weiterer häufiger Fallstrick ist die Aufnahme der Root-CA in die Kette für öffentlich zugängliche Server. Obwohl dies technisch harmlos ist, verschwendet es Bandbreite und dient keinem Zweck, da Clients bereits Root-Zertifikate in ihren Trust-Stores haben. Die Ausnahme sind interne Bereitstellungen mit einer privaten CA, bei denen das Root nicht in den Trust-Stores der Clients vorinstalliert ist und in die Kette aufgenommen oder separat auf den Clients installiert werden muss. Wenn Sie unsicher sind, ob Sie das Root einschließen sollen, lassen Sie es für öffentliche Server weg und nehmen Sie es für interne Dienste auf.
Testen Sie nach der Zusammenstellung Ihrer Kette diese immer, bevor Sie sie in der Produktion bereitstellen. Die schnellste Prüfung ist openssl verify -untrusted chain.pem leaf.pem, die die Kette durchläuft und Validierungsfehler meldet. Sie können die vollständige Bereitstellung auch mit openssl s_client -connect yourserver.com:443 testen und prüfen, ob die Ausgabe eine gültige Kette mit Einträgen der Tiefe 0, 1 und 2 zeigt. Wenn openssl s_client "Verify return code: 0 (ok)" anzeigt, ist Ihre Kette korrekt.
Häufig gestellte Fragen
Sollte ich das Root-CA-Zertifikat in die zusammengeführte Kette aufnehmen? Für öffentlich zugängliche Server nein. Root-Zertifikate sind in Client-Trust-Stores (Browsern, Betriebssystemen) vorinstalliert. Die Aufnahme des Root fügt jedem TLS-Handshake unnötige Bytes hinzu. Lassen Sie es weg, es sei denn, Sie stellen in einer Umgebung bereit, in der Clients das Root möglicherweise nicht vorinstalliert haben, wie z. B. Embedded-Systeme oder private CA-Bereitstellungen.
In welcher Reihenfolge sollten die Zertifikate vorliegen? Die korrekte Reihenfolge ist: Leaf-Zertifikat zuerst, gefolgt von Zwischenzertifikaten in der Reihenfolge vom nächsten zum Leaf bis zum nächsten zum Root, mit dem Root optional am Ende. Dieses Tool übernimmt die Sortierung automatisch. Wenn Ihre CA eine separate "CA Bundle"-Datei bereitstellt, enthält diese die Zwischenzertifikate in der korrekten Reihenfolge -- stellen Sie einfach Ihr Leaf-Zertifikat voran.
Warum erhalte ich nach der Bereitstellung meiner Kette den Fehler "unable to get local issuer certificate"? Dieser Fehler bedeutet typischerweise, dass ein erforderliches Zwischenzertifikat in Ihrer Kette fehlt. Verwenden Sie den PEM Bundle Splitter, um zu untersuchen, welche Zertifikate tatsächlich in Ihrer Datei enthalten sind, und fügen Sie dann fehlende Zwischenzertifikate hinzu. Überprüfen Sie auch, ob die Kette in der korrekten Reihenfolge vorliegt -- einige Server sind empfindlich gegenüber der Reihenfolge.
Kann ich Zertifikate von verschiedenen CAs zusammenführen? Nicht zu einer einzelnen gültigen Kette. Eine Zertifikatskette muss einem einzigen Vertrauenspfad folgen, bei dem der Issuer jedes Zertifikats mit dem Subject des nächsten Zertifikats übereinstimmt. Zertifikate von verschiedenen CAs haben unterschiedliche Vertrauenspfade und können nicht zu einer Kette kombiniert werden. Wenn Sie mehrere Zertifikate bereitstellen müssen (z. B. RSA und ECDSA), konfigurieren Sie Ihren Server so, dass er separate Ketten für jedes Zertifikat verwendet.
Wie überprüfe ich, ob meine zusammengeführte Kette korrekt ist?
Verwenden Sie OpenSSL zur Validierung: openssl verify -untrusted chain.pem leaf.pem. Ein erfolgreiches Ergebnis zeigt "leaf.pem: OK" an. Sie können eine bereitgestellte Kette auch mit openssl s_client -connect yourserver.com:443 prüfen und nach "Verify return code: 0 (ok)" in der Ausgabe suchen.
Was ist, wenn meine CA eine einzelne "Full-Chain"-Datei bereitstellt? Einige CAs stellen eine einzelne Datei bereit, die bereits das Leaf und die Zwischenzertifikate in der korrekten Reihenfolge enthält. In diesem Fall können Sie sie direkt verwenden, ohne sie zusammenzuführen. Wenn Sie sich über den Inhalt unsicher sind, fügen Sie sie zunächst in den PEM Bundle Splitter ein, um jedes Zertifikat zu untersuchen, und führen Sie sie dann bei Bedarf erneut zusammen.
Verwandte Tools
- PEM Bundle Splitter - Eine bestehende Kette aufteilen, um einzelne Zertifikate vor dem erneuten Zusammenführen zu inspizieren
- X.509 Certificate Viewer - Details jedes Zertifikats untersuchen, um die korrekte Kettenzusammenstellung zu überprüfen
- Certificate Expiry Checker - Überprüfen, ob alle Zertifikate in der zusammengeführten Kette gültige Daten haben
- TLS Config Snippet Builder - Serverkonfiguration zur Verwendung mit Ihrer zusammengeführten Kette generieren
- Convert DER to PEM - DER-Zertifikate vor dem Zusammenführen in das PEM-Format konvertieren