Fügen Sie ein PEM-Zertifikat in den Zertifikat-Decoder ein und erhalten Sie Subject, Aussteller, Gültigkeit, öffentlichen Schlüssel, Erweiterungen sowie SHA-256/SHA-1-Fingerprints in einem Durchgang.
Warum das Zertifikat lesen statt dem Schlosssymbol zu vertrauen
Ein TLS-Server präsentiert sein Zertifikat bei jedem Handshake, und der Browser prüft es, bevor Sie das Vorhängeschloss sehen. Wenn eine Verbindung mit Ablauf-Fehler, Hostname-Mismatch oder Selbstsignierungs-Warnung fehlschlägt, ist das Zertifikat selbst der erste Ort, an dem Sie nachsehen sollten.
`openssl x509 -in cert.pem -text -noout` gibt dieselben Felder aus, die diese Seite dekodiert: Subject, Aussteller, Gültigkeitszeitraum, Seriennummer, Signaturalgorithmus, öffentlicher Schlüssel und Erweiterungen. Wer diese Felder versteht, verwandelt eine Wand aus Base64 in eine umsetzbare Diagnose.
openssl x509 -in cert.pem -text -nooutopenssl x509 -in cert.pem -fingerprint -sha256 -nooutPEM und DER: die beiden Formate, die Ihnen begegnen
DER ist die binäre Kodierung der Zertifikatsstruktur aus RFC 5280. PEM (RFC 7468) ist dasselbe DER, in Base64 zwischen `-----BEGIN CERTIFICATE-----` und `-----END CERTIFICATE-----` gewickelt, damit es Textkanäle passieren kann.
Server liefern meist PEM-Dateien, manche APIs exportieren jedoch direkt DER. Der Decoder akzeptiert beides: Fügen Sie den PEM-Block oder den Base64-kodierten DER-Text ein, und die Felder werden im Browser extrahiert.
Die Felder, die die meisten Debugging-Fragen beantworten
Subject und Aussteller benennen, wem das Zertifikat gehört und wer es signiert hat. Ein selbstsigniertes Zertifikat hat dasselbe Subject und denselben Aussteller — genau das sehen Sie in der Browser-Warnung.
Gültigkeit liefert „Gültig ab“ und „Gültig bis“. Abgelaufene Zertifikate verursachen weit mehr TLS-Fehler, als die meisten Entwickler erwarten; zukünftig datierte Zertifikate erscheinen, wenn die Systemuhr falsch steht.
Seriennummer und Signaturalgorithmus identifizieren das Zertifikat und die für die Signatur verwendete Kryptografie. Öffentlicher Schlüssel zeigt Algorithmus und Größe — etwa RSA 2048 — was beim Vergleich vor und nach einer Erneuerung zählt.
Sie können einen öffentlichen Schlüssel prüfen oder Dateien mit dem Hash-Generator lokal hashen, um Fingerprints mit veröffentlichten Werten abzugleichen.
Fingerprints: was sie leisten und was nicht
Ein Fingerprint ist ein Hash der DER-Bytes des Zertifikats. Zwei Zertifikate mit unterschiedlichen Bytes erzeugen unterschiedliche SHA-256-Fingerprints — das macht Fingerprints nützlich, um zu bestätigen, dass Sie das erwartete Zertifikat sehen.
Anbieter veröffentlichen manchmal den SHA-256-Fingerprint ihres Zertifikats oder Pakets. Sie können ihn lokal reproduzieren:
openssl x509 -in cert.pem -fingerprint -sha256 -noout
Vergleichen Sie diese Ausgabe mit dem SHA-256-Wert des Decoders. Eine Übereinstimmung bestätigt die exakten Bytes; sie beweist keine Vertrauenswürdigkeit — Vertrauen entsteht aus der Kette, nicht aus einem Fingerprint.
SAN und Erweiterungen: wofür das Zertifikat berechtigt ist
Subject Alternative Name (SAN) listet die Domains und Identitäten auf, die das Zertifikat abdeckt. Ein Hostname-Mismatch entsteht, wenn die Domain der URL nicht in dieser Liste steht — selbst wenn das Zertifikat gültig und nicht abgelaufen ist.
Key Usage und Extended Key Usage schränken ein, wie der Schlüssel verwendet werden darf: Signieren, Schlüsselverschlüsselung, Server- oder Client-Authentifizierung. Ein Zertifikat mit richtigen Feldern, aber falscher Verwendung scheitert in bestimmten Clients.
Basic Constraints zeigt, ob ein Zertifikat eine CA ist. Zwischen- und Root-Zertifikate tragen CA:TRUE; Blattzertifikate normalerweise CA:FALSE.
Warum lokal parsen statt in einen Online-Dienst einzufügen
Ein öffentliches Zertifikat ist kein Geheimnis, aber die Gewohnheit, Zertifikatsmaterial in beliebige Webformulare einzufügen, lohnt sich zu brechen. Dasselbe Tool, das Zertifikate dekodiert, behauptet oft auch, private Schlüssel zu verarbeiten — ein einziger Fehl-Paste genügt.
Der Decoder läuft vollständig im Browser: Beim Parsen wird keine Netzwerk-Anfrage gesendet. Überprüfen Sie es selbst: Öffnen Sie DevTools → Netzwerk und beobachten Sie das Anfrageprotokoll, während Sie ein Zertifikat einfügen — es erscheint nichts, weil nichts Ihr Gerät verlässt.
Dasselbe Prinzip gilt für den JWT-Decoder: Tokens und Schlüssel bleiben lokal, und die Ausgabe ist nur für Ihre Augen bestimmt.
FAQ
Q.Wird mein Zertifikat beim Dekodieren hochgeladen?
A.Nein. Parsen und Fingerprinting laufen lokal in Ihrem Browser. Öffnen Sie DevTools → Netzwerk und fügen Sie ein Zertifikat ein, um zu sehen, dass keine Anfrage gesendet wird.
Q.Ich habe eine vollständige Zertifikatskette eingefügt. Warum sehe ich nur ein Zertifikat?
A.Der Decoder zeigt das erste Zertifikat der Eingabe und weist darauf hin, wenn weitere Blöcke vorhanden sind. Für die Kettenprüfung dekodieren Sie jeden PEM-Block einzeln oder verwenden openssl, um die gesamte Kette anzuzeigen.
Q.Was ist der Unterschied zwischen SHA-256- und SHA-1-Fingerprints?
A.Beide sind Hashes der DER-Bytes des Zertifikats. SHA-1 ist für die meisten Zwecke abgelöst — vergleichen Sie daher SHA-256-Fingerprints, wenn ein Anbieter sie veröffentlicht, und behandeln Sie SHA-1 nur als Legacy-Referenz.
Q.Kann ich ein Zertifikat im DER-Format dekodieren?
A.Ja. Fügen Sie den Base64-kodierten DER-Text direkt ein oder wickeln Sie ihn in PEM-Header. Der Decoder erkennt beide Formen automatisch.
Referenzen
Die Felder und Strukturen oben folgen diesen Standards:
- RFC 5280 – Internet X.509 Public Key Infrastructure Certificate and CRL Profile: https://www.rfc-editor.org/rfc/rfc5280
- RFC 7468 – Textual Encodings of PKIX, PKCS, and CMS Structures (PEM): https://www.rfc-editor.org/rfc/rfc7468
- RFC 9325 – Recommendations for Secure Use of TLS and DTLS: https://www.rfc-editor.org/rfc/rfc9325
Jetzt ein Zertifikat dekodieren
Subject, Aussteller, Gültigkeit, öffentlicher Schlüssel, Erweiterungen und Fingerprints — lokal in Ihrem Browser geparst, niemals hochgeladen.
Lesen Sie das Zertifikat, bevor Sie der Fehlermeldung vertrauen
Zertifikatsfehler laufen meist auf vier Felder hinaus: Gültigkeitsdaten, Subject vs. SAN, Selbstsignierung und der öffentliche Schlüssel. Dekodieren Sie das PEM lokal, prüfen Sie diese Felder und vergleichen Sie den SHA-256-Fingerprint mit jedem veröffentlichten Wert.
Öffnen Sie den Zertifikat-Decoder, fügen Sie das PEM ein und lesen Sie die Felder selbst.