Zertifikat-Parser

X.509-Zertifikate sind das Standardformat für Public-Key-Zertifikate, die in TLS/SSL verwendet werden. Dieses Tool parst PEM-kodierte Zertifikate und zeigt Subjekt, Aussteller, Gültigkeitszeitraum, Public-Key-Details und Erweiterungen an. Unverzichtbar beim Debuggen von HTTPS-Verbindungsproblemen.

Spezifikationen

Haeufige Anwendungsfaelle

SSL/TLS-Verbindungsfehler debuggen ("Zertifikat ist abgelaufen")
Überprüfen, ob das Zertifikat die richtigen Domainnamen abdeckt
Zertifikat-Ablaufdaten für die Erneuerungsplanung prüfen
Zwischen- und Stammzertifikate in einer Kette untersuchen
Zertifikatsattribute auf Compliance-Anforderungen prüfen

Funktionen

PEM-kodierte Zertifikate parsen (-----BEGIN CERTIFICATE-----)
Subjekt und Aussteller-Distinguished-Names anzeigen
Gültigkeitszeitraum anzeigen (Nicht vor / Nicht nach)
Public-Key-Algorithmus und -Größe extrahieren
Subject Alternative Names (SANs) anzeigen
Zertifikaterweiterungen anzeigen (Key Usage, Extended Key Usage, Basic Constraints)
Authority/Subject Key Identifier anzeigen
CRL Distribution Points und Authority Information Access URLs

Beispiele

Selbstsigniertes Zertifikat

Ausprobieren →

Ein X.509-Zertifikat für example.com mit Subject Alternative Names.

Privater Schlüssel

Ausprobieren →

Ein zugehöriger RSA-Privatschlüssel im PKCS#8-Format.

Tipps

Zertifikat aus dem Browser exportieren: Schloss-Symbol klicken > Zertifikat > Details > Exportieren.
Zertifikat einer Website abrufen mit: openssl s_client -connect example.com:443
SANs (Subject Alternative Names) listen alle gültigen Domainnamen auf.
Stammzertifikate sind selbstsigniert (Aussteller = Subjekt).
Zertifikatkette prüfen mit: openssl verify -CAfile ca.pem cert.pem

Verstaendnis Zertifikat-Parser

X.509-Zertifikate sind die Vertrauensgrundlage im Internet und ermöglichen TLS/SSL-Verschlüsselung für HTTPS-Verbindungen, Code-Signierung, E-Mail-Sicherheit (S/MIME) und VPN-Authentifizierung. Ein Zertifikat bindet einen öffentlichen Schlüssel an eine Identität (Domainname, Organisation oder Einzelperson), und eine Zertifizierungsstelle (CA) bürgt für diese Bindung, indem sie das Zertifikat digital signiert.

Zertifikate werden typischerweise im PEM-Format gespeichert — Base64-kodierte DER-Daten, eingeschlossen zwischen -----BEGIN CERTIFICATE----- und -----END CERTIFICATE----- Markierungen. Ein Zertifikat enthält das Subjekt (wen das Zertifikat identifiziert), den Aussteller (wer es signiert hat), einen Gültigkeitszeitraum (Nicht-vor- und Nicht-nach-Datum), den öffentlichen Schlüssel des Subjekts und Erweiterungen, die die Verwendung steuern. Die Subject-Alternative-Name-(SAN-)Erweiterung listet alle Domainnamen auf, die das Zertifikat abdeckt.

Zertifikatketten stellen Vertrauen her, indem sie ein End-Entity-Zertifikat über ein oder mehrere Zwischen-CAs mit einer vertrauenswürdigen Stamm-CA verbinden. Wenn ein Browser sich mit einer Website verbindet, verifiziert er die Kette: Das Serverzertifikat wurde von einer Zwischen-CA signiert, die von einer Stamm-CA signiert wurde, der der Browser vertraut. Eine unterbrochene Kette — fehlende Zwischenzertifikate oder eine unbekannte Stamm-CA — verursacht den bekannten Fehler "Ihre Verbindung ist nicht privat".

Zertifikatsverwaltung ist eine häufige Ursache für Ausfälle. Abgelaufene Zertifikate verursachen sofortige Dienstunterbrechungen. Nicht übereinstimmende Domainnamen lösen Browser-Warnungen aus. Fehlende Zwischenzertifikate funktionieren in einigen Browsern (die sie möglicherweise zwischenspeichern oder abrufen), aber scheitern in anderen und in API-Clients. Die Überwachung des Zertifikatsablaufs und die Automatisierung der Erneuerung mit Tools wie Let's Encrypt und certbot ist für einen zuverlässigen Betrieb unerlässlich.

Um zu prüfen, wann ein Zertifikat abläuft, fügen Sie den PEM-Inhalt in dieses Tool ein und schauen Sie auf das Nicht-nach-Datum. Auf der Kommandozeile führen Sie openssl x509 -enddate -noout -in cert.pem für eine lokale Datei aus, oder openssl s_client -connect example.com:443 weitergeleitet an openssl x509 -noout -enddate für einen Remote-Server. Automatisierte Überwachung durch certbot, cert-manager oder dedizierte Überwachungsdienste kann rechtzeitig vor Ablauf warnen, um Ausfälle zu vermeiden.

Stammzertifikate sind selbstsigniert (der Aussteller entspricht dem Subjekt) und sind als Vertrauensanker in Browsern und Betriebssystemen vorinstalliert. Zwischenzertifikate werden von einer Stamm-CA signiert und dienen zur Signierung von End-Entity-Zertifikaten. Diese Vertrauenskette schützt den Stammschlüssel — wenn ein Zwischenzertifikat kompromittiert wird, wird nur dieses widerrufen, nicht die Stamm-CA. Server müssen die vollständige Kette senden (End-Entity plus alle Zwischenzertifikate), sollten aber nicht das Stammzertifikat selbst einschließen.

Subject Alternative Names (SANs) listen alle Domainnamen und IP-Adressen auf, für die ein Zertifikat gültig ist. Ein einzelnes Zertifikat kann mehrere Domains wie example.com, www.example.com und api.example.com mit SANs schützen. Moderne Browser verwenden SANs anstelle des Common-Name-(CN-)Feldes für die Domain-Validierung. Wildcard-Zertifikate (*.example.com) decken eine Ebene von Subdomains ab, aber nicht die Apex-Domain selbst.

Ein Zertifikat, das in Browsern funktioniert, aber in API-Clients fehlschlägt, ist ein häufiges Problem, das durch unvollständige Zertifikatketten verursacht wird. Browser sind toleranter — einige rufen fehlende Zwischenzertifikate automatisch über AIA (Authority Information Access) ab oder verwenden zuvor zwischengespeicherte Zwischenzertifikate. API-Clients wie curl, Node.js und Pythons requests-Bibliothek erfordern typischerweise, dass die vollständige Kette vom Server gesendet wird. Stellen Sie sicher, dass Ihr Server so konfiguriert ist, dass er das End-Entity-Zertifikat plus alle Zwischenzertifikate sendet, und testen Sie mit curl -v oder openssl s_client, um die Vollständigkeit der Kette zu überprüfen.

← Zurueck zu allen Tools