Sagt mir das, ob meinem Zertifikat vertraut wird?

Nein. Vertrauen hängt an einem Vertrauensspeicher und einer Signaturprüfung, und beides ist aus einer eingefügten Datei nicht möglich. Berichtet wird, was das Zertifikat über sich selbst sagt, und ob die Namen in einer Kette zusammenpassen.

Meine Seite läuft in Chrome auf dem Laptop, scheitert aber mobil. Worauf schauen?

Fast immer auf ein fehlendes Zwischenzertifikat. Desktop-Browser laden das fehlende Zertifikat oft selbst nach und verdecken das Problem; andere Clients nicht. Fügen Sie hier die vollständige Kette ein — wird die Verbindung zwischen zwei Zertifikaten als unterbrochen gemeldet, ist dort die Lücke.

Warum passt der Common Name nicht zu meiner Seite?

Weil er nicht geprüft wird. Der Hostname wird über die Erweiterung für alternative Namen abgeglichen, und das seit Jahren. Sehen Sie in der Zeile der alternativen Namen nach: steht der Hostname dort nicht, deckt das Zertifikat ihn nicht ab, was auch immer der Common Name sagt.

Warum wird mein privater Schlüssel nicht decodiert?

Absichtlich. Nichts, was Sie einfügen, verlässt Ihren Browser, aber private Schlüssel in Webseiten einzufügen ist eine Gewohnheit, die man meiden sollte, und dieses Werkzeug weigert sich, sie beizubringen. Zertifikate und Signieranfragen enthalten keine Geheimnisse und werden normal decodiert.

Was ist der Unterschied zwischen einem Zertifikat und einer CSR?

Eine CSR ist das, was Sie an eine Zertifizierungsstelle schicken: Ihr Antragstellername, Ihr öffentlicher Schlüssel und die angefragten Erweiterungen, von Ihnen signiert. Ein Zertifikat ist das, was zurückkommt, mit dem Namen der CA als Aussteller, einem Gültigkeitsfenster und einer Seriennummer. Dieses Werkzeug decodiert beides.

Wird mein Zertifikat irgendwohin gesendet?

Nein. Zerlegen, Decodieren und Fingerabdrücke laufen alle in Ihrem Browser; nichts, was Sie einfügen, verlässt Ihr Gerät.

Zertifikat- und PEM-Decoder

Decodiert X.509-Zertifikate und Signieranfragen aus PEM — Antragsteller, Aussteller, Gültigkeit, alternative Namen, Erweiterungen und Fingerabdrücke.

PEM-Eingabe

Fügen Sie oben PEM ein, dann wird es hier decodiert.

Was dieses Werkzeug tut

Ein Zertifikat kommt als Base64-Block zwischen zwei Zeilen aus Bindestrichen an, und ansehen lässt sich ihm nichts. Dieses Werkzeug decodiert es: an wen und von wem es ausgestellt wurde, wann es abläuft, welche Hostnamen es abdeckt, welchen Schlüssel es enthält und jede Erweiterung, die es trägt. Fügen Sie eine ganze Kette ein, und jedes Zertifikat wird gegen das nächste geprüft.

Alles läuft in Ihrem Browser. Das zählt hier mehr als bei den meisten Werkzeugen — die Alternative ist meist, ein Produktivzertifikat auf den Server eines Fremden zu kopieren, oder sich an den openssl-Aufruf zu erinnern, was fast niemand tut.

PEM ist nur die Verpackung

Die Bindestriche und das Base64 sind Verpackung. Darin steckt DER, eine binäre Codierung einer Struktur namens ASN.1, und die Bezeichnung zwischen den Bindestrichen sagt, welche Struktur zu erwarten ist:

CERTIFICATE           ein ausgestelltes X.509-Zertifikat
CERTIFICATE REQUEST   eine CSR: was Sie bei einer CA angefragt haben
PUBLIC KEY            ein blosser Schluessel, ohne Identitaet
PRIVATE KEY           die geheime Haelfte, hier abgelehnt

Dasselbe Zertifikat kann auch als rohes DER in einer .cer- oder .crt-Datei ankommen, ohne Bindestriche und ohne Base64. Öffnet sich eine Datei als binäres Rauschen statt als Text, ist genau das der Fall: erst nach Base64 codieren oder als PEM exportieren.

Was wirklich in einem Zertifikat steht

Die Kernfelder sind in jedem je ausgestellten Zertifikat dieselben:

Antragsteller — um wen es im Zertifikat geht. Bei einer Website ist das heute meist nur noch ein Common Name, oft nicht mehr.
Aussteller — die Zertifizierungsstelle, die signiert hat. Ihr Antragstellername erscheint wortgleich als Aussteller von allem, was sie signiert, und genau das macht die Kettenprüfung möglich.
Gültigkeit — zwei absolute Zeitpunkte, immer in UTC. Dieses Werkzeug zeigt beide und rechnet die verbleibende Zeit in Ihrem Browser aus, denn die Maschine, die diese Seite erzeugt hat, weiß nicht, wann Sie sie lesen.
Seriennummer — je Aussteller eindeutig und die Kennung, mit der ein Zertifikat gesperrt wird.
Signaturalgorithmus — womit der Aussteller signiert hat, etwa SHA-256 mit ECDSA.
Öffentlicher Schlüssel — Typ und Größe. Bei RSA ist das die Bitlänge des Modulus; bei EC ist sie eine Eigenschaft der benannten Kurve, weshalb P-256 immer 256 Bit hat.

Ein Feld, das man erwartet und nicht mehr findet: der Common Name des Antragstellers ist nicht das, was Browser prüfen. Für den Abgleich des Hostnamens wird er seit Jahren ignoriert. Entscheidend ist die Erweiterung für alternative Namen, siehe unten.

Die Erweiterungen, die über das Funktionieren entscheiden

Ein Zertifikat kann beliebig viele Erweiterungen tragen. Fünf entscheiden darüber, ob es tatsächlich akzeptiert wird, und die decodiert dieses Werkzeug vollständig:

Alternative Namen des Antragstellers — die Hostnamen, IP-Adressen oder E-Mail-Adressen, für die das Zertifikat gilt. Dieses Feld prüfen Browser, und ein Zertifikat, dessen alternative Namen den eingegebenen nicht enthalten, wird abgelehnt, so korrekt alles andere auch sein mag.
Basiseinschränkungen — ob dies eine Zertifizierungsstelle ist und wie viele Zwischenzertifikate darunter liegen dürfen. Ein Endzertifikat, das als CA markiert ist, oder umgekehrt, zerbricht die Kette.
Schlüsselverwendung — wofür der Schlüssel überhaupt verwendet werden darf: Signieren, Schlüsselverschlüsselung, Zertifikatssignatur. Fast immer als kritisch markiert, was Software zwingt, das Zertifikat abzulehnen, statt eine unbekannte Verwendung zu übergehen.
Erweiterte Schlüsselverwendung — der Zweck: TLS-Server, TLS-Client, Codesignatur, E-Mail. Ein Zertifikat ohne TLS-Serverauthentifizierung wird keine Website ausliefern, und das überrascht regelmäßig bei Zertifikaten, die für etwas anderes ausgestellt wurden.
Schlüsselkennungen von Antragsteller und Aussteller — kurze Hashes, mit denen Software ein Zertifikat schnell seinem Aussteller zuordnet, wenn mehrere denselben Namen tragen.

Jede weitere Erweiterung erscheint mit ihrem Namen, sofern bekannt, ihrer OID und dem Hinweis, ob sie kritisch ist. Nichts wird stillschweigend verworfen: eine Erweiterung, die dieses Werkzeug nicht decodiert, wird trotzdem aufgeführt, damit sichtbar bleibt, dass es sie gibt.

Ketten, und was „lückenlos“ hier heißt

Ein Server sendet fast nie ein einzelnes Zertifikat. Er sendet sein eigenes plus die Zwischenzertifikate, die nötig sind, um eine Wurzel zu erreichen, der der Client bereits vertraut. Die Reihenfolge zählt, und die Datei heißt meist fullchain.pem:

Block 1   Endzertifikat  subject: example.com     issuer: Example CA R3
Block 2   Zwischenzert.  subject: Example CA R3   issuer: Example Root
Block 3   Wurzel         meist weggelassen, der Client hat sie schon

Jedes Zertifikat nennt seinen Aussteller, und das nächste Zertifikat darunter sollte genau diesen Namen als Antragsteller führen. Dieses Werkzeug vergleicht die beiden Namen Byte für Byte und sagt, ob sie übereinstimmen. Das ist die einzige offline prüfbare Beziehung, und sie fängt die beiden Fehler ab, die die meisten Kettenprobleme erklären: ein weggelassenes Zwischenzertifikat und Blöcke in der falschen Reihenfolge.

Diese Fehler haben ein typisches Symptom. Desktop-Browser überdecken ein fehlendes Zwischenzertifikat oft, indem sie es selbst nachladen — die Seite sieht auf dem Laptop gut aus und scheitert auf dem Telefon, in einer App oder mit curl. Wenn das Ihr Problem beschreibt, fügen Sie zuerst die vollständige Kette hier ein.

Was dieses Werkzeug nicht sagt

Es prüft keine Signaturen und kann es nicht. Zu prüfen, ob ein Zertifikat wirklich von seinem Aussteller signiert wurde, erfordert dessen öffentlichen Schlüssel; zu entscheiden, ob diesem Aussteller zu glauben ist, erfordert einen Vertrauensspeicher. Eine eingefügte Datei liefert keines von beidem. Auch eine Sperrprüfung ist nicht möglich, sie verlangt eine Netzwerkanfrage an die CA.

„Die Kette ist lückenlos“ heißt hier also, dass die Namen zusammenpassen, nicht dass die Kette gültig ist. Eine Kette gefälschter Zertifikate würde perfekt zusammenpassen. Wofür die Prüfung taugt, ist das Finden struktureller Fehler in Ihrer eigenen Konfiguration — und genau darauf schaut man, wenn man eine Kette in einen Decoder einfügt.

Fingerabdrücke und private Schlüssel

Der SHA-256-Fingerabdruck ist ein Hash des gesamten Zertifikats, und er ist das, was man mit einem genannten Wert oder einem Pin vergleicht. Beachten Sie, was er identifiziert: das Zertifikat, nicht den Schlüssel darin. Ein erneuertes Zertifikat für denselben Schlüssel hat einen anderen Fingerabdruck — der übliche Grund, warum ein Pin bei der Erneuerung bricht. Der SHA-1-Fingerabdruck wird ebenfalls gezeigt, weil ältere Werkzeuge und Konsolen ihn noch ausgeben — nur zur Identifikation; signieren darf SHA-1 nichts mehr.

Private Schlüssel werden erkannt und abgelehnt. Nichts, was hier eingefügt wird, verlässt den Browser, die Ablehnung betrifft also nicht diese Seite: Einen privaten Schlüssel in ein Webformular einzufügen ist eine Gewohnheit, die man sich besser nicht zulegt, und die nächste Seite, die danach fragt, läuft womöglich nicht lokal. Wenn Sie prüfen müssen, ob Schlüssel und Zertifikat zusammengehören, vergleichen Sie lokal den öffentlichen Schlüssel aus dem Zertifikat mit dem aus dem Schlüssel abgeleiteten.

Häufig gestellte Fragen

Sagt mir das, ob meinem Zertifikat vertraut wird?: Nein. Vertrauen hängt an einem Vertrauensspeicher und einer Signaturprüfung, und beides ist aus einer eingefügten Datei nicht möglich. Berichtet wird, was das Zertifikat über sich selbst sagt, und ob die Namen in einer Kette zusammenpassen.
Meine Seite läuft in Chrome auf dem Laptop, scheitert aber mobil. Worauf schauen?: Fast immer auf ein fehlendes Zwischenzertifikat. Desktop-Browser laden das fehlende Zertifikat oft selbst nach und verdecken das Problem; andere Clients nicht. Fügen Sie hier die vollständige Kette ein — wird die Verbindung zwischen zwei Zertifikaten als unterbrochen gemeldet, ist dort die Lücke.
Warum passt der Common Name nicht zu meiner Seite?: Weil er nicht geprüft wird. Der Hostname wird über die Erweiterung für alternative Namen abgeglichen, und das seit Jahren. Sehen Sie in der Zeile der alternativen Namen nach: steht der Hostname dort nicht, deckt das Zertifikat ihn nicht ab, was auch immer der Common Name sagt.
Warum wird mein privater Schlüssel nicht decodiert?: Absichtlich. Nichts, was Sie einfügen, verlässt Ihren Browser, aber private Schlüssel in Webseiten einzufügen ist eine Gewohnheit, die man meiden sollte, und dieses Werkzeug weigert sich, sie beizubringen. Zertifikate und Signieranfragen enthalten keine Geheimnisse und werden normal decodiert.
Was ist der Unterschied zwischen einem Zertifikat und einer CSR?: Eine CSR ist das, was Sie an eine Zertifizierungsstelle schicken: Ihr Antragstellername, Ihr öffentlicher Schlüssel und die angefragten Erweiterungen, von Ihnen signiert. Ein Zertifikat ist das, was zurückkommt, mit dem Namen der CA als Aussteller, einem Gültigkeitsfenster und einer Seriennummer. Dieses Werkzeug decodiert beides.
Wird mein Zertifikat irgendwohin gesendet?: Nein. Zerlegen, Decodieren und Fingerabdrücke laufen alle in Ihrem Browser; nichts, was Sie einfügen, verlässt Ihr Gerät.