🔒 SSL-Checker ☆

Überblick

SSL-Checker prüft das TLS-Zertifikat hinter jeder HTTPS-Website. Geben Sie eine Domain ein und das Tool führt einen echten Handshake von einem 0Appz-Server durch: Inhaber und Aussteller, exaktes Gültigkeitsfenster, Resttage bis zum Ablauf (unter 30 Tagen hervorgehoben), vollständige SAN-Liste, Seriennummer und Signaturalgorithmus, plus ausgehandelte TLS-Version und Cipher-Suite. Eine zweite verifizierte Verbindung zeigt, ob Browser dem Zertifikat vertrauen würden, sodass selbstsignierte, abgelaufene, namensfalsche oder kettenunvollständige Zertifikate klar markiert werden. Ideal zur Bestätigung von Verlängerungen, zum Debuggen von „Nicht sicher"-Warnungen und für Audits.

Was der Checker prüft

Die Prüfung öffnet eine echte TLS-Verbindung von einem 0Appz-Server und meldet genau, was der Handshake liefert: Inhaber und Aussteller, das vollständige Gültigkeitsfenster mit Resttagen, alle SANs, Seriennummer und Signaturalgorithmus sowie die ausgehandelte TLS-Version und Cipher-Suite. Eine zweite verifizierte Verbindung prüft die Kette wie Browser es tun: selbstsignierte, abgelaufene, namensfalsche und kettenunvollständige Zertifikate werden explizit markiert.

Möglichkeiten und Einschränkungen

Eigenschaft	Verhalten
Eingabe	Jeder Hostname mit HTTPS
Zertifikatsdaten	Inhaber, Aussteller, Gültigkeit, Resttage, SANs, Serie, Algorithmus
Verbindungsdaten	Ausgehandelte TLS-Version und Cipher-Suite
Vertrauensprüfung	Zweite Verbindung simuliert die Browser-Validierung
Häufige Fehler	Abgelaufen, selbstsigniert, Namensfehler, unvollständige Kette
Kosten	Kostenlos, kein Konto, unbegrenzte Prüfungen

Datenschutz: die Prüfung läuft von unserem Server

Der Handshake erfolgt serverseitig, weil Browser Zertifikatsketten nicht an JavaScript geben. 0Appz verbindet sich also mit dem eingegebenen Hostnamen; die geprüfte Domain wird nicht als Nutzerdatum gespeichert, und nichts Ihrer Verbindung wird an das Ziel weitergegeben.

Worauf achten

• Unter 30 Resttagen sofort erneuern.
• Fehlende SANs erzeugen Warnungen für Alternativnamen.
• Unvollständige Ketten brechen manche Mobilclients.
• Alte TLS-Versionen und schwache Cipher deaktivieren.
• Nach der Erneuerung prüfen, ob das neue Zertifikat ausgeliefert wird.

Mehr: Entwicklerwerkzeuge für DNS, Header, IP und Whois.

Zertifikatsketten, Ablauf und Vertrauen

Eine HTTPS-Verbindung hängt von einer Vertrauenskette ab, nicht von einem einzelnen Zertifikat. Der Server präsentiert sein Blattzertifikat plus Zwischenzertifikate, und der Browser validiert die Kette bis zu einer bereits vertrauenswürdigen Wurzel. Ein fehlendes Zwischenzertifikat ist die häufigste Fehlkonfiguration: Manche Browser cachen Zwischenzertifikate früherer Besuche und wirken fehlerfrei, während neue Besucher und mobile Clients mit einer vagen Fehlermeldung scheitern. Das Blattzertifikat muss den exakten Hostnamen abdecken, über den Common Name älterer Zertifikate oder einen Subject Alternative Name moderner, und ein Wildcard deckt nur eine Ebene ab, example.com und app.example.com brauchen also separate Einträge. Der Ablauf ist der nächste Punkt: Viele Behörden stellen Zertifikate für 90 Tage oder weniger aus, automatische Erneuerung ist daher Pflicht. Widerruf wird per OCSP oder CRL geprüft, und Stapling lässt den Server die OCSP-Antwort am Handshake befestigen. Protokoll- und Cipher-Unterstützung zählen ebenfalls: TLS 1.2 ist das praktische Minimum, TLS 1.3 bevorzugt, alles unter 1.2 sollte deaktiviert sein. Zwei verwandte Prüfungen runden das Bild: HSTS lässt Browser künftig HTTP verweigern, und gemischte Inhalte, eine HTTPS-Seite, die Bilder oder Skripte über HTTP lädt, schwächen die gesamte Verbindung still. Der Check läuft aus Ihrem Browser und speichert nichts.