SSL Certificate Checker

Wofür dient dieses Tool?

Der SSL Certificate Checker beantwortet eine Frage, die der Browser offenlässt: Ist dieses HTTPS-Zertifikat gültig, vertrauenswürdig, passt es zur Domain und wann läuft es ab? Ein Browser zeigt "sichere Verbindung" oder "Ihre Verbindung ist nicht privat" an, nie das Warum.

Das Tool öffnet eine echte TLS-Verbindung zum Host, inspiziert das Serverzertifikat und die präsentierte Kette und liefert dann ein Urteil mit klaren Zuständen. Kein "sieht in Ordnung aus". Eine Antwort.

Der Unterschied zur Adressleiste liegt in einem Punkt: Der Browser beurteilt die Verbindung so, wie er sie sieht, nachdem er im Hintergrund bereits eine wacklige Kette repariert hat. Der Checker beurteilt die Kette so, wie der Server sie wirklich ausliefert, so wie curl, ein entfernter API-Server oder ein Smartphone sie sähen. Genau diese ehrliche Sicht deckt die Phantom-Ausfälle auf.

Drei Anwendungsfälle, die immer wiederkehren:

• Vor einem Vorfall: Ein Zertifikat läuft in acht Tagen ab, keine Browser-Warnung, kompletter Ausfall am Stichtag. Sie sehen es kommen.
• Nach einem Deployment: Die Website öffnet sich bei Ihnen, aber der Webhook des Partners liefert einen TLS-Fehler zurück. Unvollständige Kette, fast immer.
• Beim Audit: Ein RSA-Schlüssel mit 1024 Bit oder eine SHA-1-Signatur, die auf einem alten internen Dienst herumliegt. Das Urteil zeigt darauf.

So lesen Sie das Urteil

Das Urteil steht in einem einzigen farbigen Wort, und dieses Wort reicht zur Entscheidung. So entschlüsseln Sie es.

Unter dem Urteil folgt das Detail: Ablaufdatum und verbleibende Tage, präsentierte Kette in der richtigen Reihenfolge, Liste der SAN, TLS-Version, Cipher, Schlüsseltyp und -größe, Signaturalgorithmus. Genug, um zu diagnostizieren, nicht nur festzustellen.

Ein Fall verdient besondere Aufmerksamkeit. Ungültig bedeutet nicht immer "kaputtes Zertifikat". Wenn die einzige Anomalie eine unvollständig ausgelieferte Kette ist, wechselt die Meldung zu einer präzisen Diagnose: Servieren Sie den Fullchain. Das Zertifikat ist gut; nur seine Auslieferung hakt.

Die konkreten Fälle, die das Tool aufdeckt

Unvollständige Kette: Der Server präsentiert nur das Serverzertifikat

Das ist der große Klassiker. Der Server sendet sein Serverzertifikat, vergisst aber das Zwischenzertifikat, das es mit der Root verbindet. Ergebnis: Die Kette führt so, wie sie ausgeliefert wird, zu keiner anerkannten Autorität zurück.

Chrome und Edge kommen damit klar: Sie laden das fehlende Zwischenzertifikat selbst herunter (AIA-Fetching). Die Website "funktioniert bei Ihnen". Aber curl scheitert, der Mail-Client scheitert, die mobile App scheitert, die HTTP-Bibliothek des Partners scheitert. Ohne dediziertes Tool ist das ein Albtraum zu diagnostizieren, denn das Symptom hängt davon ab, wer hinschaut.

Die Behebung ist eindeutig und ohne Überraschung: den Fullchain servieren, also das Serverzertifikat gefolgt vom oder von den Zwischenzertifikaten, in der richtigen Reihenfolge aneinandergehängt. Let's Encrypt liefert Ihnen direkt eine gebrauchsfertige Datei fullchain.pem.

# Die tatsächlich ausgelieferten Zertifikate zählen
openssl s_client -connect captaindns.com:443 -servername captaindns.com -showcerts </dev/null 2>/dev/null | grep -c "BEGIN CERTIFICATE"
# nur 1 Zertifikat = unvollständige Kette

Ein Sonderfall wird oft für einen Fehler des Tools gehalten: das allein ausgelieferte Serverzertifikat, das sich trotzdem verifiziert. Das passiert nur, wenn dieses Zertifikat direkt von einer Root ausgestellt wurde, was das CA/Browser Forum inzwischen untersagt. In der Praxis wird ein allein ausgeliefertes öffentliches Zertifikat als ungültig eingestuft, und die Empfehlung ist immer dieselbe: Fullchain.

Ablauf: Der Ausfall, den kein Browser ankündigt

Ein Zertifikat, das in zehn Tagen abläuft, löst keine Warnung aus. Am Stichtag bricht alles zusammen. HTTPS blockiert, API stumm, Webhooks im Fehler, und der Support steht in Flammen.

Das Tool setzt das Ablaufdatum und die verbleibenden Tage an den Anfang des Ergebnisses. Unter einem Monat wechselt es in eine Warnung. Aber eine Momentaufnahme warnt nicht: Dafür braucht es eine Überwachung, die in Schleife läuft (siehe unten).

Hostname: Die Domain fehlt in den SAN

Das Zertifikat ist gültig und vertrauenswürdig, deckt aber den angeforderten Namen nicht ab. Browser ignorieren das alte Feld Common Name: Sie lesen ausschließlich die SAN (Subject Alternative Names). Fehlt die Domain dort, folgt der Fehler NET::ERR_CERT_COMMON_NAME_INVALID, egal was der CN sagt.

Die häufigste Falle ist der Wildcard. *.captaindns.com deckt www.captaindns.com ab, aber nicht den Apex captaindns.com und auch keine tiefere Ebene wie a.b.captaindns.com. Ein Wildcard reicht nur eine Stufe weit. Die Korrektur: neu ausstellen und alle gewünschten Namen in den SAN auflisten.

Selbstsigniert: verschlüsselt, aber ohne Vertrauen

Ein selbstsigniertes Zertifikat hat denselben Aussteller und denselben Betreff. Es verschlüsselt die Verbindung, die Daten sind also geschützt unterwegs. Aber niemand garantiert, wem der Schlüssel gehört. Der Browser lehnt ab und zeigt eine Warnung.

Perfekt für einen internen Dienst oder eine Testumgebung. Auf einer öffentlichen Website ist es eine Sackgasse: Stellen Sie lieber ein kostenloses Zertifikat über Let's Encrypt aus und automatisieren Sie es mit ACME. Das Tool isoliert diesen Fall in einem eigenen Urteil, um ihn nicht mit einem kaputten Zertifikat zu verwechseln.

Schwache Krypto: die Fossilien, die herumliegen

Ein RSA-Schlüssel unter 2048 Bit, ein ECDSA-Schlüssel unter 256 Bit, eine SHA-1- oder MD5-Signatur: lauter Relikte, die auf alten, nie migrierten Diensten herumgeistern. Der Browser toleriert sie eine Weile, aber sie stehen auf der Kippe. Das Tool meldet sie auf dem Serverzertifikat, bevor eine Client-Härtung sie von einem Tag auf den anderen ablehnen lässt.

Automatisierung und Überwachung: die einzige tragfähige Strategie

Von Hand prüfen taugt für einen einzelnen Vorfall. Auf Dauer hält das nicht, und der Kalender macht es unhaltbar.

Das CA/Browser Forum verkürzt die Lebensdauer der Zertifikate schrittweise: 200 Tage im März 2026, 100 Tage 2027, 47 Tage 2029. Bei 47 Tagen wird die manuelle Erneuerung absurd. Zwei Reflexe drängen sich auf.

Die Ausstellung mit ACME automatisieren. Das ACME-Protokoll (das von Let's Encrypt, über certbot, Caddy, Traefik, lego) erneuert und installiert das Zertifikat ohne menschliches Zutun neu. Einmal konfiguriert, danach vergessen. Das ist die einzige Möglichkeit, mit dem Tempo Schritt zu halten.

Den Ablauf kontinuierlich überwachen. Die Automatisierung scheitert manchmal still: Ausstellungskontingent erreicht, DNS für die Validierung kaputt, stummer Reload-Hook. Eine Überwachung, die den Ablauf in regelmäßigen Abständen prüft und im Voraus alarmiert, fängt diese Lücken auf. Der HTTP Uptime Monitor von CaptainDNS übernimmt diese Rolle für Ihre HTTPS-Endpunkte.

Dieser Checker und der Monitor ergänzen sich: der eine diagnostiziert im Moment T, der andere hält Wache. Um den Kalender und seine Folgen zu vertiefen, lesen Sie unseren Leitfaden zur Verkürzung der Zertifikatslaufzeit auf 47 Tage. Und um von der punktuellen Prüfung zu einem umfassenden Vorgehen (Inventar, ACME-Automatisierung, Ablaufüberwachung) zu gelangen, beschreibt unser Leitfaden zum Zertifikats-Lebenszyklus die Methode.

Nur Web-HTTPS

Diese Version deckt das Web-HTTPS ab: implizite TLS-Verbindung auf host:port, Port 443 standardmäßig. Mail liegt außerhalb des Umfangs. Ein SMTP-Server verhandelt TLS in der Regel nachträglich über STARTTLS auf den Ports 25, 587 oder 465: Ein direkter Verbindungsaufbau würde dort kein Zertifikat sehen.

Für das Zertifikat eines Mailservers übernehmen zwei Tools: Der SMTP/MX Tester inspiziert das über STARTTLS präsentierte Zertifikat, und der DANE/TLSA Checker bestätigt, dass es zum im DNS veröffentlichten Fingerabdruck passt. Vermischen Sie die beiden Welten nicht: Ein Web-Zertifikat und ein MX-Zertifikat prüft man nicht auf dieselbe Weise.

FAQ - Häufig gestellte Fragen

F: Wie prüft man ein SSL-Zertifikat online?

A: Geben Sie den Domainnamen in das Host-Feld ein und starten Sie die Prüfung. Das Tool öffnet eine TLS-Verbindung zum Host und Port (443 standardmäßig), inspiziert das Serverzertifikat und die präsentierte Kette und liefert ein Urteil: Gültigkeit, Hostname-Abgleich, Systemvertrauen, Ablauf, Robustheit von Schlüssel und Signatur.

F: Was ist der Unterschied zwischen Server-, Zwischen- und Root-Zertifikat?

A: Das Serverzertifikat trägt Ihren Domainnamen. Das Zwischenzertifikat verbindet es mit der Root. Die Root (Root CA) liegt im Vertrauensspeicher des Systems. Der Server muss das Serverzertifikat gefolgt von den Zwischenzertifikaten präsentieren; die Root muss nicht gesendet werden. Diese Abfolge ist der Fullchain.

F: Warum funktioniert meine Website in Chrome, aber scheitert anderswo?

A: Das ist das Symptom eines fehlenden Zwischenzertifikats. Chrome und Edge holen das fehlende Zwischenzertifikat selbst nach (AIA-Fetching), aber curl, Mail-Clients und viele Mobilgeräte weisen die Verbindung ab. Servieren Sie die vollständige Kette (Fullchain), um es überall zu beheben.

F: Wie lange ist ein SSL-Zertifikat gültig?

A: Heute bis zu 398 Tage, aber die Laufzeit schrumpft. Das CA/Browser Forum schreibt 200 Tage im März 2026, 100 Tage 2027, 47 Tage 2029 vor. Let's Encrypt stellt bereits mit 90 Tagen aus. Bei diesem Tempo trägt die manuelle Erneuerung nicht mehr: Man muss per ACME automatisieren.

F: Wie überwacht man den Ablauf eines SSL-Zertifikats?

A: Dieser Checker liefert eine Momentaufnahme. Um vor dem Ausfall gewarnt zu werden, koppeln Sie eine kontinuierliche Überwachung mit dem HTTP Uptime Monitor: Er prüft den Ablauf in regelmäßigen Abständen und alarmiert, wenn der Termin näher rückt.

F: Was bedeutet ein selbstsigniertes Zertifikat?

A: Sein Aussteller und sein Betreff sind identisch: Es hat sich selbst signiert. Es verschlüsselt die Verbindung, bietet aber kein öffentliches Vertrauen, daher die Browser-Warnung. Gut für den internen Gebrauch; für eine öffentliche Website nehmen Sie ein Zertifikat einer anerkannten Autorität wie Let's Encrypt.

F: Was tun, wenn der Hostname nicht übereinstimmt?

A: Die angeforderte Domain steht nicht in den SAN des Zertifikats. Häufiger Fall: Ein Wildcard *.captaindns.com deckt weder den Apex noch eine tiefere Subdomain ab. Stellen Sie das Zertifikat mit allen gewünschten Namen in den SAN neu aus. Der Common Name zählt nicht mehr: Nur die SAN werden gelesen.

Ergänzende Tools

Nützliche Ressourcen

• RFC 5280 - Profil der X.509-Zertifikate (Struktur und Validierung von Zertifikaten)
• RFC 6125 - Hostname-Verifizierung (SAN-Abgleich und Wildcards)
• CA/Browser Forum - Baseline Requirements (Regeln für Ausstellung und Lebensdauer)
• Let's Encrypt Dokumentation - Kettenzertifikate (Fullchain und Zwischenzertifikate)