SSL-Zertifikat-Decoder — PEM-Zertifikate und CSRs lesen

Was in einem Zertifikat steckt

Ein X.509-Zertifikat bindet einen öffentlichen Schlüssel an einen Namen, signiert von einem Aussteller. Die Felder, die zählen, wenn etwas nicht funktioniert:

Subject Alternative Name: die Liste der Hostnamen (und IPs), für die das Zertifikat gilt. Browser ignorieren den Common Name vollständig; ein Zertifikat ohne den Hostnamen im SAN scheitert mit NET::ERR_CERT_COMMON_NAME_INVALID, egal was der CN sagt.
Gültigkeit: notBefore und notAfter. Öffentlich vertrauenswürdige Endzertifikate dürfen höchstens 398 Tage gelten (bis 2029 sinkend auf 47 Tage); Let's Encrypt stellt 90-Tage-Zertifikate aus.
Aussteller und die Kette: Ein Server muss sein Endzertifikat plus jedes Zwischenzertifikat bis zu (aber ohne) einer Root senden, der der Client vertraut. „Unable to get local issuer certificate“ heißt fast immer: ein Zwischenzertifikat fehlt.
Key Usage / Extended Key Usage: Ein Serverzertifikat braucht TLS Server Auth; eine CA braucht keyCertSign und CA:TRUE in den Basic Constraints.
Authority Information Access: wo das Ausstellerzertifikat und der OCSP-Responder zu holen sind; CRL Distribution Points: wo die Sperrlisten liegen.
Signaturalgorithmus: heute sha256WithRSA, ecdsa-with-SHA256 oder Ed25519; SHA-1-Signaturen werden überall abgelehnt.

Fingerabdrücke

Der SHA-256-Fingerabdruck ist der Hash des gesamten DER-kodierten Zertifikats, genutzt für Pinning und um das vom Server Gesendete mit dem Erwarteten zu vergleichen (openssl x509 -fingerprint -sha256). Er ändert sich bei jeder Erneuerung, weshalb das Pinnen von Endzertifikaten fragil ist; pinnen Sie stattdessen den öffentlichen Schlüssel (SPKI) oder ein Zwischenzertifikat.

CSRs

Ein Certificate Signing Request enthält Subject, öffentlichen Schlüssel und gewünschte Erweiterungen, signiert mit dem passenden privaten Schlüssel als Besitznachweis. CAs übernehmen den SAN aus dem Request (oder aus den validierten Domains) und ignorieren das meiste andere. Einen CSR vor dem Einreichen zu prüfen spart eine Runde, wenn der SAN falsch ist.

An das PEM kommen

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | openssl x509   # nur Endzertifikat
openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null | sed -n '/BEGIN/,/END/p'                   # ganze Kette
openssl x509 -in cert.der -inform der -out cert.pem                                                                        # DER → PEM

Fragen

Kann ich eine .crt-, .cer- oder .der-Datei einfügen?

Fügen Sie den Text von PEM-Dateien ein (.pem, .crt, .cer, wenn sie mit -----BEGIN beginnen). Binäres DER muss zuerst konvertiert werden: openssl x509 -inform der -in datei -out datei.pem. Rohes Base64 eines DER-Zertifikats ohne BEGIN/END-Zeilen wird ebenfalls akzeptiert.

Warum sagt der Decoder, der CN sei nicht im SAN?

Browser prüfen nur den SAN. Ein Zertifikat mit CN=example.com, aber SAN=www.example.com funktioniert nicht für example.com. Lassen Sie es mit jedem Hostnamen im SAN neu ausstellen.

Was bedeutet hier „selbstsigniert“?

Aussteller und Subject sind identisch. Das ist normal für eine Root-CA und für Entwicklungszertifikate, aber ein selbstsigniertes Endzertifikat lehnen Browser ab, sofern es nicht als vertrauenswürdig installiert ist.

Wird mein Zertifikat an einen Server gesendet?

Nein. Das Dekodieren nutzt einen in JavaScript geschriebenen ASN.1-Parser und läuft in Ihrem Browser. Private Schlüssel werden trotzdem sofort abgelehnt; ein Zertifikat ist von Natur aus öffentlich, ein Schlüssel nie.