Zum Inhalt springen

SSL-Zertifikat prüfen

SSL Certificate Checker

Verbindet sich mit einem Host, zeigt die gelieferte Kette, das Ablaufdatum, Protokoll- und Cipher-Unterstützung und markiert Lücken in der Kette.

Verbindet sich per TLS mit einem Host und berichtet, was tatsächlich ausgeliefert wurde: die Zertifikatskette vom Endzertifikat bis zur Wurzel, die verbleibenden Tage jedes Zertifikats, die Protokollversionen, die der Server annimmt und nicht annimmt, und die ausgehandelte Cipher-Suite. Jeder Befund stammt aus einem echten Handshake und nicht aus einer Datenbank.

☁️ Nutzt unseren Serverssltlscertificatesecurity

Unser Server stellt diese Anfrage für Sie. An ihn geht nur der Hostname – weder Ihre Cookies noch Ihr Anmeldestatus gehen mit. Der Server verbindet sich ausschließlich mit öffentlichen Adressen und verweigert private und interne.

Standardmäßig Port 443. Die übrigen Ports, auf denen die Verbindung mit TLS beginnt — 8443, 465, 993, 995, 636 und 853 —, werden akzeptiert, sonst keiner. Der Hostname geht per SNI mit, also liefert auch eine geteilte IP das richtige Zertifikat.

So funktioniert es

  1. Geben Sie den Host ein, mit Port, wenn es nicht 443 ist

    example.com oder example.com:8443. Ports, die sofort mit TLS beginnen – 8443, 465, 993, 995, 636, 853 –, funktionieren alle; STARTTLS-Ports wie 587 nicht.

  2. Lesen Sie das Urteil, dann die Befunde

    Das Urteil ist eine Zusammenfassung der Befunde darunter, jeder markiert als gut, Hinweis, Vorsicht oder Problem. Ablauf innerhalb von dreißig Tagen und eine unvollständige Kette sind die zwei, die am häufigsten zählen.

  3. Prüfen Sie die Reihenfolge der Kette, nicht nur das Endzertifikat

    Die Kette wird in der Reihenfolge gezeigt, in der der Server sie gesendet hat. Ein Server, der sein Zwischenzertifikat weglässt, funktioniert in Chrome, das das fehlende nachlädt, und scheitert in curl und auf älterem Android – eine Klasse von Fehlern, die wochenlang wie „bei mir geht es“ aussieht.

  4. Sehen Sie nach, welche Protokollversionen angenommen werden

    Jede Version wird in einer eigenen Verbindung probiert, die Zeile ist also ein Fakt über den Server, keine Folgerung. Angenommenes TLS 1.0 und 1.1 ist ein Befund, auf den man reagieren sollte; sie wurden mit RFC 8996 abgekündigt.

Häufige Fragen

Es sagt, das Zertifikat sei gültig, aber mein Browser beschwert sich

Meist die Kette, der Name oder die Uhr. Prüfen Sie, dass das Zwischenzertifikat ausgeliefert wird, dass der Host, den Sie eintippen, in der SAN-Liste steht – Browser ignorieren den CN vollständig – und dass das Datum des Geräts stimmt. Ein Gerät mit falscher Uhr weist einwandfreie Zertifikate ab.

Kann ich einen internen Server prüfen?

Nein. Die Verbindung geht von unserem Server aus, und der ausgehende Weg verweigert private und Loopback-Adressen. Für einen internen Host liefert openssl s_client -connect host:443 -servername host dieselbe Kette lokal.

Warum liefert eine geteilte IP trotzdem das richtige Zertifikat?

Weil der Hostname beim Handshake als SNI gesendet wird, und so weiß der Server, welches Zertifikat er vorzeigen soll. Das ist auch der Grund, warum sich eine bloße IP-Adresse hier nicht prüfen lässt.

Prüft es die Sperrung?

Nein. OCSP und CRL werden nicht abgefragt, ein gesperrtes, aber nicht abgelaufenes Zertifikat gilt hier also als gültig. Das ist eine echte Grenze: Gezeigt wird, was der Server ausgeliefert hat und ob Kette und Daten standhalten.

Eingabe aus

Danach

Diese Tools nehmen an, was dieses hier erzeugt, das Ergebnis kann also direkt weiter.