SSL-Zertifikat auslesen

Wann du ein Zertifikat auslesen musst

Der häufigste Fall ist auch der banalste: das Ablaufdatum. Dein Anbieter hat dir die Datei des neuen Zertifikats geschickt, oder du musst das alte erneuern, und das Hosting-Panel sagt es dir nicht. Hier siehst du als Erstes die Zahl der verbleibenden Tage, und wenn das Zertifikat schon abgelaufen oder noch nicht gültig ist, siehst du das vor allem anderen, in Rot oder Gelb.

Dazu kommen drei weitere typische Fälle. Der Browser meldet „Zertifikat ungültig“, und du willst wissen, ob es an den Namen liegt (das Zertifikat deckt diese Subdomain nicht ab) oder an der Kette (auf dem Server fehlt ein Teil). Du musst eine Zertifikatsignierungsanforderung (CSR) an die Zertifizierungsstelle schicken und willst vor dem Bezahlen prüfen, ob die richtigen Namen darin stehen. Oder eine .cer- oder .p7b-Datei kommt per E-Mail bei dir an, und du willst wissen, was sie ist, bevor du sie installierst.

Die Seite nimmt eingefügtes PEM (auch mehrere Zertifikate hintereinander), .crt-, .cer-, .pem- und .der-Dateien, CSRs und .p7b-Dateien an und erkennt den Typ am Inhalt, nicht an der Endung.

Abgedeckte Namen: Der Common Name zählt nicht mehr

Die Namen, für die ein Zertifikat gilt, stehen in den alternativen Antragstellernamen (SAN), und sie sind das Einzige, was heutige Browser ansehen: Chrome hat 2017 aufgehört, den Common Name (CN) zu lesen, Safari 2019. Ein Zertifikat, das den richtigen Namen nur im CN hat, führt heute zu einem Fehler.

Die Wildcard gilt nur für eine einzige Ebene. Ein Zertifikat für *.example.com deckt www.example.com und shop.example.com ab, aber nicht example.com allein (dafür braucht es einen weiteren Namen) und auch nicht a.b.example.com (dafür bräuchte es *.b.example.com). Gib den Namen ins Feld „Zu prüfender Name“ ein, und du bekommst ein klares Ja oder Nein, mit dem Namen im Zertifikat, der ihn abdeckt.

Unter den Namen gibt es manchmal auch IP-Adressen, typisch für das NAS oder den Router zu Hause: Dort gilt das Zertifikat nur für genau diese Adresse, und ein Domainname, der auf dieselbe Adresse zeigt, reicht nicht. Um mit Adressen und Netzen zu rechnen, gibt es den Subnetzrechner.

Die Kette und warum die Reihenfolge zählt

Eine Website schickt nicht nur ein Zertifikat: Sie schickt ihr eigenes, ausgestellt von einem Zwischenzertifikat, das wiederum von einem Stammzertifikat ausgestellt wurde, das der Browser schon kennt. Die Verbindung steht in den Zertifikaten selbst: Der Aussteller (Issuer) jedes Zertifikats muss der Antragsteller (Subject) des nächsten sein. Fügst du die ganze Kette ein, prüft die Seite die Glieder einzeln.

Ist die Reihenfolge falsch, bekommst du die Kette schon neu sortiert, fertig zum Kopieren in die Datei, die der Server schickt (die viele Panels fullchain nennen). Der häufigste Fehler ist aber ein anderer: das fehlende Zwischenzertifikat. Manche Browser holen es sich selbst, und die Website scheint zu funktionieren, während curl, viele Handy-Apps und viele Programme einen Fehler melden. Fügst du ein, was der Server schickt, und nach dem Zertifikat der Website kommt nichts, ist das das Problem. Und wenn du die Datei erstellt hast, indem du zwei Dateien mit cat zusammengefügt hast, prüfe, ob zwischen einer END-Zeile und dem nächsten BEGIN ein Zeilenumbruch steht: Kleben sie aneinander, findet OpenSSL überhaupt kein Zertifikat, und die Seite weist darauf hin.

Es gibt auch einen subtileren Fall: ein Zwischenzertifikat mit dem richtigen Namen und dem falschen Schlüssel. Das passiert, wenn eine Zertifizierungsstelle ihren Schlüssel erneuert und die alte Datei auf dem Server liegen bleibt. Die Namen passen, aber die Schlüsselkennungen nicht, und die Seite weist darauf hin. In .p7b-Dateien gibt es dagegen keine Reihenfolge, weil die Zertifikate dort als ungeordnete Menge stehen: Die Seite zeigt sie schon aufgereiht von der Website bis zum Stammzertifikat.

Datumsangaben: Zeitzone, Tage und maximale Laufzeit

Die Datumsangaben in einem Zertifikat sind immer in koordinierter Weltzeit (UTC) angegeben, und so findest du sie hier auch. In Deutschland ist es im Winter eine Stunde und im Sommer zwei Stunden später, also ist ein Zertifikat, das am 3. um 23:30 UTC abläuft, in Berlin am 4. schon abgelaufen. Die verbleibenden Tage sind ganze Tage zu 24 Stunden, gezählt ab dem Moment, in dem du liest.

Dann gibt es die Laufzeit. Seit September 2020 darf ein öffentliches Website-Zertifikat nicht länger als 398 Tage gelten, und die Regeln des CA/Browser Forums verkürzen das weiter: 200 Tage für Zertifikate, die ab dem 15. März 2026 ausgestellt werden, 100 ab dem 15. März 2027, 47 ab dem 15. März 2029. Gilt ein Website-Zertifikat länger, als an seinem Ausstellungstag erlaubt war, weist die Seite darauf hin: Kommt es von einer öffentlichen Zertifizierungsstelle, lehnt der Browser es ab, kommt es von einer firmeninternen Zertifizierungsstelle, gilt die Regel nicht.

Ein Detail, an dem selbstgebaute Parser scheitern: Bis 2049 hat das Jahr nur zwei Ziffern, und „50“ bedeutet 1950, nicht 2050, so will es der Standard (RFC 5280).

Schlüssel, Signatur und Fingerabdrücke

Der Schlüssel sagt dir, wie stark das Zertifikat ist. Ein RSA-Schlüssel mit 2048 Bit ist das akzeptierte Minimum, 3072 oder 4096 sind langsamer und stärker; Schlüssel mit elliptischen Kurven P-256 und P-384 sind bei gleicher Sicherheit kürzer. Ed25519 gibt es in Zertifikaten, aber Browser akzeptieren es für Websites noch nicht. Unter 2048 Bit und bei SHA-1- oder MD5-Signaturen zeigt die Seite eine Warnung, denn genau das sind die Fälle, in denen ein Browser das Zertifikat ablehnt.

Die Fingerabdrücke SHA-256 und SHA-1 sind die Prüfsumme des ganzen Zertifikats, hier mit den kryptografischen Funktionen des Browsers berechnet: Damit vergleicht man zwei Zertifikate, ohne sie zu lesen, zum Beispiel am Telefon mit dem, der den Server betreut, und es ist dieselbe Zahl, die Windows, macOS und OpenSSL anzeigen. Der SHA-1-Fingerabdruck ist hier nur eine Kennung und keine Signatur, und er ist das, was Windows als „Fingerabdruck“ anzeigt (englisch „Thumbprint“). Für den Fingerabdruck einer beliebigen Datei, nicht eines Zertifikats, gibt es Datei-Prüfsumme.

Die Seriennummer ist das, wonach dich die Zertifizierungsstelle fragt, um ein Zertifikat zu widerrufen. Die Zeilen OCSP und CRL sagen, wo der Browser nachfragt, ob es widerrufen wurde: Die Seite zeigt sie an, verbindet sich aber nicht mit ihnen.

Namen mit Umlauten und Akzenten, auf vier Arten geschrieben

In einem Zertifikat kann Text auf verschiedene Arten kodiert sein, und ein hastig geschriebener Parser behandelt alle als UTF-8. Hier wird jede Kodierung als das gelesen, was sie ist: UTF8String als UTF-8, BMPString als UTF-16, der alte UniversalString als UTF-32. Der schwierige Fall ist der T61String, der in echten Zertifikaten mal UTF-8 und mal Latin-1 enthält: Die Seite versucht das erste und nimmt, wenn die Bytes kein UTF-8 sind, das zweite, so wie OpenSSL. So bleibt „Müller GmbH“ auch „Müller GmbH“, statt zu einer Reihe von Symbolen zu werden, und wenn Latin-1 nötig war, sagt es die Seite.

Was es nicht kann, offen gesagt

Es prüft die Signatur nicht und sagt nicht, ob man dem Zertifikat vertrauen kann: Es zeigt, was darin steht. Um zu wissen, ob eine Website richtig eingerichtet ist, brauchst du eine Prüfung, die sich mit dem Server verbindet, und das kann eine Webseite nicht, weil Browser dem Code einer Seite das Zertifikat einer anderen Website nicht herausgeben. Um es zu bekommen, klicke auf das Schloss neben der Adresse und exportiere das Zertifikat, oder nutze openssl s_client -connect example.com:443 -showcerts und füge hier ein, was herauskommt.

Es öffnet keine .pfx- und .p12-Dateien: Sie enthalten den privaten Schlüssel und sind mit einem Passwort verschlüsselt. Und wenn du einen privaten Schlüssel zusammen mit dem Zertifikat einfügst, liest die Seite ihn nicht und warnt dich, denn ein privater Schlüssel darf nie irgendwo eingefügt werden. Um ein Zugriffstoken zu lesen, das etwas anderes ist, auch wenn es ähnlich aussieht, gibt es den JWT-Decoder.