Zertifikat Check
TLS-Zertifikat eines Hosts prüfen: Vertrauenskette, Laufzeit, Version, Cipher.
Ein TLS-Zertifikat weist die Identität eines Servers nach und liefert den Schlüssel für die verschlüsselte Verbindung. Ist es abgelaufen, für einen anderen Namen ausgestellt oder von keiner bekannten Zertifizierungsstelle signiert, brechen Browser und HTTPS-Clients die Verbindung mit einer Warnung ab. Bei Mailservern mit Weboberflächen (Webmail, Autodiscover, OWA) führt das direkt zu nicht erreichbaren Diensten.
Was dieses Werkzeug prüft
Es baut eine echte TLS-Verbindung zum eingegebenen Host auf Port 443 auf, ohne STARTTLS-Vorlauf. Geprüft wird die Vertrauenskette gegen das öffentliche CA-Bundle, das Ablaufdatum und ob der eingegebene Name durch das Zertifikat abgedeckt ist (Subject Alternative Name, wildcard-fähig). Zusätzlich werden die ausgehandelte TLS-Version, die Cipher-Suite, Schlüsseltyp und Schlüssellänge des Zertifikats sowie der Signaturalgorithmus ausgewiesen. Schlägt die Vertrauensprüfung fehl, holt ein zweiter, rein informativer Verbindungsversuch trotzdem die Zertifikatsdetails.
Das Ergebnis lesen
Grün heißt: Kette vertrauenswürdig, nicht abgelaufen, Hostname abgedeckt, TLS 1.2 oder höher. Anders als beim SMTP Test auf Port 25 (opportunistisches TLS) ist ein nicht vertrauenswürdiges oder abgelaufenes Zertifikat hier ein Fehler, weil ein Browser die Seite dann nicht öffnet. Gewarnt wird bei TLS unter 1.2, bei RSA-Schlüsseln unter 2048 Bit und bei einem Signaturalgorithmus mit SHA-1 oder MD5. Eine Restlaufzeit von wenigen Tagen erscheint als Warnung, damit die Erneuerung nicht verpasst wird.
Grundlagen
Aufbau und Prüfung von X.509-Zertifikaten regelt RFC 5280, die Zuordnung von Hostnamen zu Zertifikaten (SAN vor Common Name) RFC 6125 und RFC 9525. TLS 1.2 ist in RFC 5246 beschrieben, TLS 1.3 in RFC 8446; die älteren Versionen SSL 3, TLS 1.0 und TLS 1.1 gelten als überholt (RFC 8996). Dieses Werkzeug bewertet die Cipher-Suite nicht systematisch wie SSL Labs, es zeigt, was ein moderner Standard-Client aushandelt.
Typische Fehlerbilder und wie man sie behebt
- Zertifikat abgelaufen. Erneuern und die komplette Kette (Leaf plus Zwischenzertifikate) austauschen. Bei Let's Encrypt prüfen, warum die automatische Verlängerung nicht lief (Cron, Port 80 erreichbar, Webroot-Pfad).
- Hostname passt nicht. Der aufgerufene Name steht weder als SAN noch über eine passende Wildcard im Zertifikat. Ein Zertifikat ausstellen, das alle genutzten Namen als SAN führt, oder den Dienst auf den Namen umstellen, für den das Zertifikat gilt. Der Common Name allein reicht seit Jahren nicht mehr.
- Unbekannte Zertifizierungsstelle. Fast immer fehlt das Zwischenzertifikat in der ausgelieferten Kette. Die vom Aussteller bereitgestellte Chain-Datei vollständig einbinden, Reihenfolge Leaf, dann Intermediate.
- Selbstsigniert. Für öffentlich erreichbare Dienste ein Zertifikat einer anerkannten CA verwenden (kostenlos über Let's Encrypt). Selbstsignierte Zertifikate sind nur für geschlossene, manuell verteilte Umgebungen tragbar.
- Alte TLS-Version oder schwache Signatur. Auf dem Server TLS 1.0 und 1.1 abschalten, mindestens TLS 1.2 anbieten und ein Zertifikat mit SHA-256-Signatur und einem RSA-Schlüssel ab 2048 Bit oder einem ECDSA-Schlüssel verwenden.
Häufige Fragen
- Welcher Port wird geprüft?
- Immer Port 443 (HTTPS) mit TLS von Anfang an. Für STARTTLS auf Port 25 gibt es den SMTP Test; für IMAP, POP3 und Submission ist ein eigenes Werkzeug geplant.
- Was heißt 'nicht vertrauenswürdig'?
- Die Zertifikatskette lässt sich nicht bis zu einer öffentlichen Stammzertifizierungsstelle zurückverfolgen, oder der Hostname passt nicht, oder das Zertifikat ist abgelaufen oder noch nicht gültig. Ein Browser würde die Verbindung mit einer Warnung blockieren.
- Mein Zertifikat ist abgelaufen, was jetzt?
- Neu ausstellen und die vollständige Kette austauschen, dann den Dienst neu laden. Wenn die automatische Verlängerung (z. B. Let's Encrypt) nicht griff, die Ursache beheben: der Renew-Job muss regelmäßig laufen und die ACME-Validierung erreichbar sein.
- Fehler 'Hostname stimmt nicht überein', woran liegt das?
- Der aufgerufene Name ist im Zertifikat nicht als Subject Alternative Name hinterlegt und wird auch von keiner Wildcard abgedeckt. Ein Zertifikat beantragen, das alle tatsächlich genutzten Namen als SAN enthält.
- Warum wird die Cipher-Suite angezeigt, aber nicht benotet?
- Welche Cipher ausgehandelt wird, hängt von der Präferenzliste des Clients ab. Dieses Werkzeug zeigt, was ein moderner Standard-Client bekommt, es probiert nicht systematisch alle Kombinationen wie SSL Labs.
- Wird eine IP-Adresse als Eingabe akzeptiert?
- Ja, das Feld nimmt einen FQDN oder eine IP-Adresse (dieselbe Validierung wie beim DNS Lookup). Bei einer IP ohne passenden SAN wird die Hostname-Prüfung erwartungsgemäß scheitern.