Certificate Decoder

01

So funktioniert’s

1. 1

   Füg die ganze Kette ein, nicht ein einzelnes Zertifikat

   Ein Block wird dekodiert. Mehrere werden dekodiert und dann gegeneinander geprüft: Nennt Zertifikat 1 Zertifikat 2 als Aussteller, und 2 wiederum 3? Genau diese Prüfung beantwortet, warum eine Seite im Browser funktioniert und in curl scheitert – und sie ist der Grund, mehr einzufügen, als du für nötig hältst.

2. 2

   Die Befunde lesen

   Abgelaufen oder bald ablaufend, noch nicht gültig, SHA-1-Signaturen, Schlüssel unter 2048 Bit, kein Subject Alternative Name, eine Gültigkeit über den 398 Tagen, die Browser akzeptieren, selbstsigniert, Reichweite eines Wildcards und CA:TRUE bei etwas, das sich als Webserver ausgibt.

3. 3

   Einen CSR prüfen, bevor du dafür bezahlst

   Ein CSR-Decoder ist die letzte Chance, einen Tippfehler im Hostnamen zu finden, bevor eine Zertifizierungsstelle signiert und dir dafür Geld berechnet. Er zeigt das Subject, den Schlüssel, mit dem der CSR erzeugt wurde, und die SANs – die in einem CSR zwei Ebenen tiefer liegen als in einem Zertifikat und die mehrere Tools komplett übersehen.

02

Funktioniert in Chrome, scheitert in curl

03

Auch die Reihenfolge zählt

#1  secure.example.com        ✗ not issued by the next one
#2  Tekk Test Root CA

04

Was markiert wird

05

CSRs, bevor du bezahlst

06

Was er nicht tut

07

Häufige Fragen

Speichert oder verschickt ihr mein Zertifikat irgendwohin?

Nein. Das Dekodieren passiert in der Seite – kein Server-Aufruf, kein Log, kein Konto. Zertifikate sind öffentliche Dokumente, daher ist das hier weniger wichtig als auf manchen anderen Seiten. Ein CSR und die internen Hostnamen darin sind aber nicht öffentlich, und es gibt keinen Grund, dass einer davon dein Gerät verlassen muss, um gelesen zu werden.

Liest er meinen Private Key?

Nein, und er verweigert sofort die Arbeit, wenn einer eingefügt wird. Nichts, was dieser Certificate Decoder tut, braucht einen Schlüssel: Zertifikat und CSR sind beide per Design öffentlich. Wenn ein Private Key irgendwo eingefügt wurde, wo er nicht hingehört, betrachte ihn als kompromittiert und stell das Zertifikat neu aus, statt zu hoffen.

Mein Zertifikat funktioniert in Chrome, aber curl und Java lehnen es ab. Warum?

Fast immer fehlt ein Zwischenzertifikat. Dein Server muss sein eigenes Zertifikat und jedes Zwischenzertifikat darüber mitschicken; nur dem Root-Zertifikat muss der Client schon vertrauen. Browser überspielen eine Lücke stillschweigend, indem sie das fehlende Zertifikat selbst holen – curl, Java, Go und Python tun das nicht. Füg die ganze Kette hier ein, und du siehst, ob jedes Zertifikat wirklich vom nächsten in der Datei ausgestellt wurde.

In welcher Reihenfolge muss die Kette stehen?

Zuerst das Leaf-Zertifikat, dann jeder Aussteller darüber, das Root-Zertifikat optional. Umgedrehte oder gemischte Ketten lehnen strenge Clients ab, obwohl jedes Zertifikat in der Datei gültig ist. Der Certificate Decoder zeigt die Reihenfolge, in der du eingefügt hast, und markiert bei jedem Glied, ob es anschließt oder nicht. So sieht eine falsche Reihenfolge anders aus als ein fehlendes Zertifikat – beide haben dasselbe Symptom und brauchen unterschiedliche Fixes.

Wie entscheidet er, ob zwei Zertifikate verknüpft sind?

Er vergleicht die rohen DER-Bytes des Issuer-Felds eines Zertifikats mit dem Subject-Feld des nächsten. Genau der Vergleich des angezeigten Texts lässt andere Checker bei Namen danebenliegen, die gleich aussehen, aber unterschiedlich kodiert sind – ein PrintableString und ein UTF8String mit denselben Zeichen sind für einen Verifier nicht derselbe Name.

Prüft er die Signatur?

Nein. Um zu prüfen, ob der Schlüssel des Ausstellers das Zertifikat wirklich signiert hat, braucht es dessen Public Key und eine Signaturoperation. Ein Browser könnte das, aber die Antwort würde nur wiederholen, was dein eigener TLS-Stack bei jeder Verbindung ohnehin prüft. Was sich hier zu wissen lohnt – ist die Kette vollständig, stimmt die Reihenfolge, ist etwas abgelaufen, deckt es den Hostnamen ab –, ergibt sich allein aus den Zertifikaten.

Warum steht da, dass es keinen Subject Alternative Name gibt?

Weil es keinen gibt – und das Zertifikat damit auf gar keinen Hostnamen passt. Chrome hat 2017 aufgehört, den Common Name als Hostnamen zu lesen, und alle anderen sind gefolgt. Ein Zertifikat mit CN=example.com und ohne SAN sieht in einem SSL-Decoder, der nur Felder ausgibt, völlig korrekt aus – und scheitert in jedem Browser, der es zu sehen bekommt.

Was deckt ein Wildcard eigentlich ab?

Ein Label, und nur eins. *.example.com passt auf api.example.com, aber nicht auf v2.api.example.com und auch nicht auf example.com selbst, es sei denn, der nackte Name steht als eigener SAN drin. Den meisten Wildcard-Zertifikaten in Produktion fehlt dieser zweite Eintrag, und niemand merkt es, bis jemand die Apex-Domain aufruft.

Warum wird ein Zertifikat markiert, das länger als 398 Tage gültig ist?

Weil erst Apple, dann Google und Mozilla öffentlich vertrauenswürdige Zertifikate 2020 auf 398 Tage begrenzt haben und Clients längere ablehnen, egal wer sie signiert hat. Ein Zertifikat mit zehn Jahren Laufzeit von einer internen CA ist völlig normal; dasselbe Zertifikat in einem Browser ist es nicht.

Kann er neben Zertifikaten auch einen CSR dekodieren?

Ja. Als CSR-Decoder zeigt er das Subject, den Public Key, mit dem der CSR erzeugt wurde, den Signaturalgorithmus und die SANs aus dem extensionRequest-Attribut – die zwei Ebenen tiefer sitzen als in einem Zertifikat. Deshalb zeigen manche Tools einen CSR ganz ohne SANs, und du merkst es erst nach der Ausstellung.

Lohnt sich ein CSR-Check, bevor ich ein Zertifikat kaufe?

Es ist die billigste Prüfung, die es gibt. Ein CSR-Checker findet einen vertippten Hostnamen, ein fehlendes www, einen 1024-Bit-Schlüssel oder den falschen Organisationsnamen, solange die Korrektur noch nichts kostet. Danach heißt es: neu ausstellen und bei manchen Zertifizierungsstellen warten.

Welche Formate nimmt er an?

PEM – die Base64-Blöcke, die mit -----BEGIN CERTIFICATE----- oder -----BEGIN CERTIFICATE REQUEST----- beginnen. Mehrere Blöcke in einem Paste werden als Kette gelesen. Binäre .der-, .cer- und .pfx-Dateien musst du vorher umwandeln, das erledigt openssl lokal mit einem Befehl.

Warum nicht einfach openssl?

Nimm openssl. Es ist auf der Maschine und maßgeblich. Diesen Certificate Decoder gibt es für die Momente, in denen es nicht zur Hand ist – ein Laptop ohne openssl, ein Handy, der Bildschirm von jemand anderem im Team – und weil openssl x509 -text alles auf einmal ausgibt, in DER-Feldreihenfolge, ohne zu sagen, was davon ein Problem ist.

Ist ein SSL Certificate Decoder dasselbe wie ein SSL-Checker?

Nein, und der Unterschied liegt darin, was du einfügst. Ein SSL-Checker verbindet sich mit einem Live-Hostnamen und meldet, was dieser Server schickt – dafür muss der Server erreichbar und öffentlich sein. Ein Decoder liest eine Datei, die du schon hast: eine, die noch nicht deployt ist, hinter einem VPN liegt oder per E-Mail von der Person kam, die das Zertifikat gekauft hat. Beides ist nützlich; nur eins funktioniert, bevor etwas live ist.

Warum ist das kostenlos, und was ist Tekk?

Tekk macht dein Produkt zu Software, die sich selbst verbessert: 16 Loops beobachten deine Codebase, bringen dir Proposals, die du mit Greenlight freigibst oder ablehnst, und dein Coding-Agent baut das Ergebnis. Diese Seite kostet im Betrieb nichts, weil nichts auf unseren Servern läuft – deshalb gibt es keine Anmeldepflicht, kein Limit und keinen Upsell im Tool.