PEM-Bundle-Splitter

Der PEM Bundle Splitter trennt eine Datei mit mehreren verketteten PEM-Zertifikaten in einzelne Zertifikate auf, wobei End-Entity-, Zwischen- und Root-Zertifikate in der Kette identifiziert werden -- unverzichtbar für die Fehlersuche bei TLS-Kettenproblemen und das Extrahieren bestimmter Zertifikate aus Bundles. Fügen Sie ein PEM-Bundle mit mehreren -----BEGIN CERTIFICATE------Blöcken ein und erhalten Sie jedes Zertifikat einzeln mit identifiziertem Subject und Issuer.

Zertifikatsbundles und -ketten verstehen

Wenn Sie TLS auf einem Webserver einrichten, installieren Sie nicht nur ein einzelnes Zertifikat. Sie benötigen eine Kette von Zertifikaten, die das Leaf-Zertifikat Ihres Servers mit einer Root-CA verknüpft, der Clients vertrauen. Das Leaf-Zertifikat sagt "Ich bin example.com, und ich wurde von Intermediate CA R3 signiert." Das Zwischenzertifikat sagt "Ich bin R3, und ich wurde von ISRG Root X1 signiert." Das Root-Zertifikat sagt "Ich bin ISRG Root X1, und ich habe mich selbst signiert." Clients verifizieren diese Kette von unten nach oben, und wenn ein Glied fehlt oder defekt ist, schlägt die Verbindung fehl.

Zertifizierungsstellen liefern diese Zertifikate typischerweise als einzelne PEM-Datei mit mehreren verketteten Zertifikatsblöcken -- ein Bundle. Manchmal ist das Bundle in der richtigen Reihenfolge, manchmal nicht, und manchmal enthält es Zertifikate, die Sie nicht benötigen (wie das Root, das Clients bereits haben). Das Problem ist, dass ein PEM-Bundle nur eine Wand aus Base64-Text mit sich wiederholenden BEGIN/END-Markierungen ist, und es ist nahezu unmöglich, durch Betrachten des Rohtexts zu erkennen, welches Zertifikat welches ist.

Dieser Splitter löst dieses Problem. Fügen Sie Ihr Bundle ein, und das Tool trennt jedes Zertifikat, parst seine Subject- und Issuer-Felder und kennzeichnet es als Leaf, Zwischen- oder Root-Zertifikat. Sie können dann jedes Zertifikat einzeln inspizieren, neu ordnen, unerwünschte entfernen oder bestimmte Zertifikate für die Verwendung in verschiedenen Konfigurationen kopieren. Es ist ein unverzichtbares Debugging-Tool, wenn Sie einen "certificate not trusted"- oder "unable to verify the first certificate"-Fehler erhalten und herausfinden müssen, was tatsächlich in Ihrer Kettendatei enthalten ist.

So teilen Sie ein PEM-Zertifikatsbundle auf

1. Fügen Sie Ihr PEM-Bundle ein, das mehrere -----BEGIN CERTIFICATE------Blöcke enthält
2. Das Tool identifiziert und trennt jedes Zertifikat im Bundle
3. Überprüfen Sie die geparsten Subject- und Issuer-Informationen für jedes extrahierte Zertifikat
4. Kopieren oder laden Sie einzelne Zertifikate nach Bedarf herunter

Beispiel: Aufteilen einer Drei-Zertifikats-Kette

Eingabe -- ein verkettetes PEM-Bundle:

-----BEGIN CERTIFICATE-----
MIIFjTCCBHWgAwIBAgIS...  (leaf certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFFjCCAv6gAwIBAgIR...  (intermediate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFYDCCBEigAwIBAgIQ...  (root)
-----END CERTIFICATE-----

Ausgabe -- drei einzeln identifizierte Zertifikate:

Wann sollte man dieses Tool verwenden

• Debugging von TLS-Handshake-Fehlern -- eine Kette aufteilen, um fehlende Zwischenzertifikate, falsche Reihenfolge oder doppelte Zertifikate zu identifizieren, die SSL-Fehler verursachen
• Extraktion bestimmter Zertifikate -- ein einzelnes Zwischenzertifikat aus einem von einer Zertifizierungsstelle bereitgestellten Bundle herausziehen
• Neuordnung der Zertifikatskette -- einige Webserver erfordern eine bestimmte Reihenfolge (Leaf zuerst, dann Zwischenzertifikate); die Kette aufteilen, um sie korrekt wieder aufzubauen
• Audit von Zertifikatsbundles -- schnell identifizieren, was sich in einer Bundle-Datei befindet, ohne openssl x509 für jedes Zertifikat manuell auszuführen
• Plattformübergreifende Vorbereitung -- Zertifikate einzeln für Systeme extrahieren, die separate Dateien erfordern (z. B. Java-KeyStore-Importe)
• Incident Response -- eine Kette von einem fehlerhaften Server schnell zerlegen, um zu identifizieren, welches Zertifikat das Problem verursacht

Wie PEM-Zertifikatsketten funktionieren

Ein PEM-Bundle ist einfach eine Verkettung mehrerer PEM-Zertifikate in einer einzelnen Datei. Jedes Zertifikat beginnt mit -----BEGIN CERTIFICATE----- und endet mit -----END CERTIFICATE-----, mit Base64-kodierten DER-Daten zwischen den Markierungen.

Korrekte Kettenreihenfolge

Die Standard-Kettenreihenfolge für TLS-Server ist:

1. Leaf-Zertifikat -- das Zertifikat Ihres Servers (das für Ihre Domain)
2. Zwischenzertifikat(e) -- eine oder mehrere CAs zwischen dem Leaf und dem Root
3. Root-Zertifikat (optional) -- der Vertrauensanker; die meisten Konfigurationen lassen dies weg, da Clients Root-Zertifikate in ihrem Trust-Store haben

Häufige Kettenprobleme, die der Splitter erkennt

Anforderungen verschiedener Server-Software an Kettendateien

Verschiedene Server handhaben Kettendateien unterschiedlich:

• nginx -- ssl_certificate erwartet das Leaf plus Zwischenzertifikate in einer Datei, Leaf zuerst
• Apache -- SSLCertificateFile für das Leaf, SSLCertificateChainFile für Zwischenzertifikate
• HAProxy -- einzelne Datei mit Leaf + Zwischenzertifikaten + privatem Schlüssel verkettet
• IIS -- importiert PKCS#12-Bundles (.pfx) über die GUI; Kette wird separat installiert

Debugging von Zertifikatsketten in der Praxis

Das häufigste Kettenproblem ist ein fehlendes Zwischenzertifikat. Dies ist schwierig zu diagnostizieren, da Desktop-Browser oft problemlos funktionieren -- sie cachen Zwischenzertifikate aus früheren Verbindungen und können fehlende über die Authority Information Access (AIA)-Erweiterung abrufen. Aber Nicht-Browser-Clients wie curl, Pythons requests-Bibliothek, mobile Apps und IoT-Geräte führen kein AIA-Abrufen durch. Sie verlassen sich vollständig darauf, dass der Server eine vollständige Kette sendet. Wenn Ihre Website in Chrome funktioniert, aber in curl fehlschlägt, ist ein fehlendes Zwischenzertifikat fast sicher die Ursache.

Um dies zu diagnostizieren, rufen Sie die Kette von Ihrem Server mit openssl s_client -connect yourserver.com:443 -showcerts ab, fügen Sie die Ausgabe in diesen Splitter ein und prüfen Sie, ob alle Zwischenzertifikate vorhanden sind. Vergleichen Sie den Issuer jedes Zertifikats mit dem Subject des nächsten. Wenn es eine Lücke gibt -- der Issuer eines Zertifikats stimmt nicht mit dem Subject eines anderen Zertifikats im Bundle überein -- haben Sie ein fehlendes Zwischenzertifikat, das hinzugefügt werden muss.

Ein weiteres häufiges Problem ist die Aufnahme des Root-Zertifikats in die Kette. Obwohl dies technisch kein Fehler ist, verschwendet es Bandbreite, da Clients bereits Root-Zertifikate in ihren Trust-Stores haben. Jeder TLS-Handshake sendet die vollständige Kette, sodass ein unnötiges Root-Zertifikat von 1-2 KB bei Millionen von Verbindungen ins Gewicht fällt. Verwenden Sie den Splitter, um das Root zu identifizieren (seine Subject- und Issuer-Felder sind identisch) und es aus Ihrem Bundle zu entfernen, es sei denn, Sie stellen in Umgebungen mit nicht standardmäßigen Trust-Stores bereit.

Häufig gestellte Fragen

Wie erkenne ich, welches Zertifikat das Leaf und welche Zwischenzertifikate sind? Das Leaf-Zertifikat (End-Entity) hat ein Subject, das mit Ihrem Domainnamen übereinstimmt, und sein Issuer ist eine CA, nicht es selbst. Zwischenzertifikate haben ein Subject, das mit dem Issuer des darunter liegenden Zertifikats in der Kette übereinstimmt. Ein Root-Zertifikat ist selbstsigniert -- sein Subject und sein Issuer sind identisch.

Warum funktioniert mein Browser, aber andere Clients schlagen fehl? Browser cachen oft Zwischenzertifikate aus früheren Verbindungen oder rufen fehlende Zwischenzertifikate über die Authority Information Access (AIA)-Erweiterung ab. Nicht-Browser-Clients (curl, mobile Apps, API-Clients) führen typischerweise kein AIA-Abrufen durch und schlagen daher fehl, wenn Ihr Server keine vollständige Kette sendet. Verwenden Sie den Splitter, um zu überprüfen, ob Ihr Bundle alle erforderlichen Zwischenzertifikate enthält.

Sollte ich das Root-Zertifikat in mein Bundle aufnehmen? Im Allgemeinen nein. Root-Zertifikate sind in Client-Trust-Stores vorinstalliert, sodass deren Sendung Bandbreite verschwendet (typischerweise 1-2 KB pro Handshake). Einige spezialisierte Umgebungen (Embedded-Geräte, interne CAs) erfordern jedoch möglicherweise das Root in der Kette. Der Splitter identifiziert Root-Zertifikate, damit Sie entscheiden können, ob Sie sie einschließen.

Was ist, wenn mein Bundle Zertifikate in der falschen Reihenfolge enthält? Teilen Sie das Bundle auf, identifizieren Sie die Rolle jedes Zertifikats und setzen Sie es dann mit dem PEM Bundle Merger wieder zusammen, der automatisch die korrekte Reihenfolge bestimmt. Die meisten modernen Webserver tolerieren Ketten in falscher Reihenfolge, aber einige ältere Clients können fehlschlagen, wenn das Leaf nicht an erster Stelle steht.

Wie erhalte ich die Zertifikatskette von einem laufenden Server? Führen Sie openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null aus, um die vollständige Kette im PEM-Format abzurufen. Kopieren Sie die Ausgabe einschließlich aller BEGIN/END CERTIFICATE-Blöcke und fügen Sie sie in den Splitter ein.

Verwandte Tools

• PEM Bundle Merger - Einzelne Zertifikate wieder zu einer korrekt geordneten Kette zusammensetzen
• X.509 Certificate Viewer - Die vollständigen Details jedes extrahierten Zertifikats inspizieren
• Certificate Expiry Checker - Ablaufdaten für jedes Zertifikat in der Kette prüfen
• SAN Extractor - Subject Alternative Names aus dem Leaf-Zertifikat extrahieren
• Convert DER to PEM - Binäre DER-Zertifikate vor dem Bündeln in PEM konvertieren