X.509-Zertifikat-Viewer

X.509-Zertifikatdetails aus PEM anzeigen

PEM Certificate

Certificate Details

Paste a PEM certificate to view its details

Der X.509-Zertifikat-Viewer analysiert PEM-kodierte SSL/TLS-Zertifikate und zeigt Subject, Issuer, Gueltigkeit, Schluesseldetails, Erweiterungen und Fingerabdruecke in einem menschenlesbaren Format an -- alles lokal in Ihrem Browser verarbeitet, ohne Zertifikate auf externe Server hochzuladen. Fuegen Sie einen Wert wie -----BEGIN CERTIFICATE-----...-----END CERTIFICATE----- ein und sehen Sie sofort jedes Feld dekodiert.

X.509-Zertifikate verstehen

Wenn Sie mit Webservern, Load Balancern oder einem beliebigen Dienst arbeiten, der HTTPS spricht, haben Sie staendig mit X.509-Zertifikaten zu tun. Ein X.509-Zertifikat ist im Wesentlichen ein digital signiertes Dokument, das einen oeffentlichen Schluessel an eine Identitaet bindet -- ueblicherweise einen Domainnamen oder eine Organisation. Wenn ein Browser ueber TLS eine Verbindung zu Ihrem Server herstellt, empfaengt er das Zertifikat, prueft, ob eine vertrauenswuerdige Zertifizierungsstelle es signiert hat, und verifiziert, dass die Domain in der Adressleiste mit den im Zertifikat aufgefuehrten Namen uebereinstimmt. Wenn etwas nicht stimmt -- falsche Domain, abgelaufenes Datum, nicht vertrauenswuerdiger Aussteller -- schlaegt die Verbindung fehl und Benutzer sehen eine abschreckende Warnseite.

Das Problem ist, dass Zertifikate in ASN.1 DER kodiert sind, einem Binaerformat, das ohne Tools voellig unlesbar ist. Selbst der PEM-Wrapper, der die Binaerdaten Base64-kodiert und Kopf-/Fusszeilen hinzufuegt, liefert nichts als eine Wand aus Zeichen. Sie koennen einem PEM-Block nicht ansehen, ob das Zertifikat Ihre Domain abdeckt, wann es ablaeuft oder ob es einen ausreichend starken Schluessel verwendet. Genau dafuer ist ein Zertifikat-Viewer da: Er dekodiert die Binaerstruktur und praesentiert jedes Feld im Klartext, damit Sie die Korrektheit vor der Produktionsbereitstellung ueberpruefen koennen.

Dieser Viewer ist besonders nuetzlich fuer Zertifikate, die Sie nicht auf Drittanbieter-Inspektionsdienste hochladen koennen oder sollten. Interne CA-Zertifikate, Client-Authentifizierungszertifikate und Zertifikate mit proprietaeren Organisationsdetails verdienen alle eine Inspektion in einem Tool, das alles lokal verarbeitet. Fuegen Sie den PEM-Text ein, ueberpruefen Sie die dekodierte Ausgabe und bestaetigen Sie, dass Subject-Namen, Gueltigkeitsdaten, Schluesselstaerke und Erweiterungen alle Ihren Erwartungen entsprechen.

So betrachten Sie ein X.509-Zertifikat

Oeffnen Sie das X.509-Zertifikat-Viewer-Tool
Fuegen Sie Ihr PEM-kodiertes Zertifikat ein (beginnend mit -----BEGIN CERTIFICATE-----)
Der Viewer analysiert und zeigt sofort alle Zertifikatsfelder an
Ueberpruefen Sie das dekodierte Subject, den Issuer, den Gueltigkeitszeitraum, die Schluesselinformationen und die Erweiterungen
Kopieren Sie Fingerabdruecke oder spezifische Felder nach Bedarf

X.509-Zertifikatsfelder erklaert

Subject und Issuer

Das Subject identifiziert, fuer wen das Zertifikat ausgestellt wurde. Der Issuer identifiziert die Zertifizierungsstelle (CA), die es signiert hat. Beide verwenden das Distinguished-Name-Format (DN):

Feld	Abkuerzung	Beispiel
Common Name	`CN`	`www.example.com`
Organisation	`O`	`Example Inc.`
Organisationseinheit	`OU`	`IT Department`
Land	`C`	`US`
Bundesland/Provinz	`ST`	`California`
Ort	`L`	`San Francisco`

Schluesselinformationen

Der Viewer zeigt den Public-Key-Algorithmus und die Staerke an:

RSA 2048-Bit -- Minimum fuer Produktionszertifikate
RSA 4096-Bit -- hoehere Sicherheit, etwas langsamere Handshakes
ECDSA P-256 -- aequivalent zu RSA 3072-Bit mit besserer Performance
ECDSA P-384 -- von einigen Compliance-Frameworks gefordert

Zertifikatserweiterungen

Moderne Zertifikate stuetzen sich auf Erweiterungen fuer kritische Funktionalitaet:

Subject Alternative Names (SANs) -- alle Hostnamen und IPs, die das Zertifikat abdeckt
Key Usage -- erlaubte Operationen (digitalSignature, keyEncipherment)
Extended Key Usage -- spezifische Zwecke (serverAuth, clientAuth)
Basic Constraints -- ob das Zertifikat andere Zertifikate signieren kann (CA:TRUE/FALSE)
Authority Information Access -- OCSP-Responder- und CA-Issuer-URLs

Beispiel fuer Zertifikatsausgabe

Das Einfuegen eines typischen Let's Encrypt-Zertifikats erzeugt:

Subject:    CN=www.example.com
Issuer:     CN=R3, O=Let's Encrypt, C=US
Not Before: 2025-01-15 00:00:00 UTC
Not After:  2025-04-15 23:59:59 UTC
Serial:     04:A3:2B:9C:...
Algorithm:  RSA 2048-bit
SHA-256:    A1:B2:C3:D4:E5:F6:...
SHA-1:      1A:2B:3C:4D:5E:...

SANs:
  DNS: www.example.com
  DNS: example.com

Wann Sie dieses Tool verwenden sollten

Vor-Bereitstellungs-Verifizierung -- Zertifikatsinhalte ueberpruefen, ob sie mit Ihrer Domain und der beabsichtigten Konfiguration uebereinstimmen, bevor Sie es auf einem Server installieren
Fehlersuche bei TLS-Fehlern -- Zertifikate inspizieren, um nicht uebereinstimmende CNs, fehlende SANs oder abgelaufene Gueltigkeitszeitraeume zu finden
Sicherheitsaudits -- Schluesselstaerke, Signaturalgorithmus und Erweiterungskonfiguration ueber Ihren Zertifikatsbestand ueberpruefen
Zertifikatketten-Inspektion -- jedes Zertifikat in einer Kette untersuchen, um End-Entity-, Zwischen- und Root-CAs zu identifizieren
Behandlung privater Zertifikate -- interne oder private CA-Zertifikate inspizieren, ohne sie auf Drittanbieter-Dienste hochzuladen
Vorfallreaktion -- ein verdaechtiges Zertifikat aus einer Paketerfassung oder Logdatei schnell dekodieren, um seine Legitimitaet zu bewerten

Wie X.509-Zertifikate funktionieren

X.509 ist der ITU-T-Standard, der das Format von Public-Key-Zertifikaten definiert. Jede HTTPS-Verbindung stuetzt sich auf X.509-Zertifikate, um Vertrauen herzustellen. Das Zertifikat bindet einen oeffentlichen Schluessel an eine Identitaet (Domainname, Organisation) und ist kryptografisch von einer vertrauenswuerdigen Zertifizierungsstelle signiert.

Zertifikatsstruktur

Ein X.509v3-Zertifikat enthaelt diese Top-Level-Felder:

Certificate:
  Version:            v3 (0x2)
  Serial Number:      eindeutiger Bezeichner, von der CA zugewiesen
  Signature Algorithm: z.B. sha256WithRSAEncryption
  Issuer:             DN der signierenden CA
  Validity:
    Not Before:       Beginn des Gueltigkeitsfensters
    Not After:        Ende des Gueltigkeitsfensters
  Subject:            DN des Zertifikatsinhabers
  Subject Public Key Info:
    Algorithm:        RSA, ECDSA oder Ed25519
    Public Key:       die tatsaechlichen Schluesseldaten
  Extensions:         SANs, Key Usage, AIA usw.
  Signature:          digitale Signatur der CA ueber alle Felder

Kodierungsformate

Zertifikate werden im ASN.1 DER-Format (binaer) kodiert und dann typischerweise in PEM (Base64 mit Kopf-/Fusszeilen) fuer die menschliche Handhabung eingewickelt. Die Markierungen -----BEGIN CERTIFICATE----- und -----END CERTIFICATE----- begrenzen die Base64-kodierten DER-Daten. Sie koennen das Zertifikat eines Servers im PEM-Format mit OpenSSL abrufen:

openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null

Zertifikatsinspektion in der Praxis

Die wichtigste Gewohnheit bei der Arbeit mit Zertifikaten ist, sie vor der Bereitstellung zu inspizieren. Es dauert dreissig Sekunden, ein Zertifikat in einen Viewer einzufuegen und zu bestaetigen, dass das Subject mit Ihrer Domain uebereinstimmt, die SANs alle benoetigten Hostnamen abdecken, die Gueltigkeitsdaten angemessen sind und der Schluesselgorithmus Ihren Sicherheitsanforderungen entspricht. Diesen Schritt zu ueberspringen, fuehrt dazu, dass Teams ein Zertifikat fuer die falsche Domain bereitstellen oder einen SAN-Eintrag fuer eine API-Subdomain vergessen, was erst auffaellt, wenn Monitoring-Alarme um 2 Uhr nachts ausloesen.

Bei der Fehlersuche von TLS-Fehlern beginnen Sie damit, das Zertifikat zu erhalten, das der Server tatsaechlich praesentiert. Fuehren Sie openssl s_client -connect ihrserver.com:443 -servername ihrserver.com aus und fuegen Sie die PEM-Ausgabe in diesen Viewer ein. Vergleichen Sie die dekodierten Felder mit dem, was Sie erwarten: Ist der CN oder SAN korrekt? Ist das Zertifikat abgelaufen? Ist der Issuer die CA, die Sie beabsichtigt haben? Viele TLS-Probleme, die aus einer Fehlermeldung mysterioees erscheinen, werden offensichtlich, wenn man die tatsaechlichen Zertifikatsfelder neben den Erwartungen sieht.

Fuer Organisationen, die Dutzende oder Hunderte von Zertifikaten verwalten, ist der Aufbau einer regelmaessigen Inspektionsroutine wertvoll. Exportieren Sie Zertifikate von Ihren Servern, fuegen Sie sie in den Viewer ein und pruefen Sie auf bevorstehende Ablaeufe, schwache Schluesselgroessen (RSA 1024 haette schon vor Jahren ausgemustert werden sollen) oder veraltete Signaturalgorithmen. Diese Art von proaktivem Audit erkennt Probleme, bevor sie zu Ausfaellen werden.

Haeufig gestellte Fragen

Was ist der Unterschied zwischen CN und SAN in einem Zertifikat? Der Common Name (CN) ist ein Legacy-Feld im Subject, das historisch den Domainnamen enthielt. Moderne Browser verwenden jetzt ausschliesslich Subject Alternative Names (SANs) fuer die Hostname-Validierung. Ein Zertifikat mit CN=example.com aber ohne passenden SAN-Eintrag wird in Chrome und Firefox die Validierung nicht bestehen. Stellen Sie immer sicher, dass Ihre Domains in der SAN-Erweiterung erscheinen.

Wie bekomme ich den PEM-Text fuer ein Zertifikat, das ich inspizieren moechte? Verwenden Sie OpenSSL auf der Kommandozeile: openssl s_client -connect example.com:443 -showcerts gibt PEM-Zertifikate aus. Sie koennen auch aus den Browser-Entwicklertools (Sicherheits-Tab) exportieren oder PEM-Dateien in Server-Konfigurationen finden -- sie haben typischerweise die Endungen .pem, .crt oder .cer.

Kann dieser Viewer Zertifikatsketten verarbeiten? Ja. Wenn Sie mehrere PEM-Zertifikate (eine vollstaendige Kette) einfuegen, analysiert der Viewer jedes einzeln. Zum Aufteilen von Ketten in einzelne Zertifikate verwenden Sie den PEM-Bundle-Splitter.

Was bedeutet "CA:TRUE" in der Basic-Constraints-Erweiterung? Ein Zertifikat mit CA:TRUE in seinen Basic Constraints ist berechtigt, andere Zertifikate zu signieren -- es ist ein Zertifizierungsstellen-Zertifikat, kein Blatt-Zertifikat. Blatt-Zertifikate, die von Webservern verwendet werden, sollten immer CA:FALSE zeigen. Wenn Sie CA:TRUE auf einem Zertifikat sehen, von dem Sie erwarten, dass es ein Serverzertifikat ist, stimmt etwas mit Ihrer Konfiguration nicht.

Warum zeigt mein Zertifikat einen anderen Issuer als die CA, von der ich es gekauft habe? Zertifizierungsstellen verwenden oft Zwischenzertifikate, um Blatt-Zertifikate zu signieren, anstatt direkt mit ihrem Root zu signieren. Das Issuer-Feld zeigt den Namen der Zwischen-CA, nicht des Root. Dies ist normal und erwartet. Sie koennen die vollstaendige Kette nachverfolgen, indem Sie die Subject- und Issuer-Felder jedes Zertifikats vom Blatt bis zum Root untersuchen.

Wie kann ich feststellen, ob ein Zertifikat einen ausreichend starken Schluessel verwendet? Ueberpruefen Sie den Abschnitt Schluesselinformationen. Fuer RSA sind 2048 Bit das aktuelle Minimum; 4096 Bit bieten zusaetzlichen Spielraum. Fuer ECDSA bietet P-256 (256 Bit) Sicherheit aequivalent zu RSA 3072-Bit. Jeder RSA-Schluessel unter 2048 Bit sollte sofort ersetzt werden, da CAs keine Zertifikate fuer kleinere Schluessel ausstellen und Browser sie moeglicherweise ablehnen.