Eingaben
Beispiel
example.com:443 -> Ergebnisse getrennter exakter Versions-Probes, verifizierte Zertifikatsidentität, ausgehandelte Cipher-/ALPN-Evidenz und HTTPS-spezifische HSTS-Evidenz.
TLS-Konfigurationsprüfung
Führt getrennte exakte TLS-Versions-Probes aus und fasst verifizierte Zertifikatsidentität, ausgehandelte Cipher-/ALPN-Evidenz und HTTPS-spezifische HSTS-Evidenz zusammen.
Nutze es für einen kompakten TLS-Check, ohne gleich einen vollständigen externen SSL-Labs-ähnlichen Scan zu starten.
Der erste Blick auf das, was ein Server wirklich anbietet
Wenn TLS kaputtgeht, geht es selten laut kaputt. Ein für den falschen Hostnamen erneuertes Zertifikat, ein Load Balancer mit akzeptiertem TLS 1.0 oder ein h2-Angebot, das nur HTTP/1.1 aushandelt, tauchen oft erst später auf: als Browserwarnung, scheiternder API-Client, Performance-Untersuchung oder Audit-Befund.
Dieser Checker führt getrennte, exakt erzwungene Probes für TLS 1.0, 1.1, 1.2 und 1.3 sowie einen separaten Peer- und Hostnamen-validierenden Default-Handshake aus. Unterstützt, abgelehnt, lokal nicht verfügbar, Verbindungsfehler und anderweitig unvollständige Evidenz bleiben getrennt. Ausgehandelte Version, Cipher, Zertifikat-SAN-Match und ALPN beschreiben nur den jeweiligen Handshake; eine vollständige Cipher- oder ALPN-Enumeration wird nicht behauptet. HSTS und HTTP/2/3 werden nur für DNS-Namen auf HTTPS-Port 443 bewertet.
Die Probe lesen wie im Incident-Einsatz
Nutze für gewöhnliche Virtual-Host-Prüfungen den DNS-Hostnamen, weil der Checker bei DNS-Namen SNI sendet. Ein öffentliches IP-Literal ist nur für explizite IP-Endpunkt-Prüfungen zulässig und wird ohne SNI gegen iPAddress-SAN-Einträge geprüft; damit kann der Default-Virtual-Host statt des Zertifikats für Nutzerzugriffe per Name erscheinen.
Lies die Ergebnisse als Gesamtbild. Ein erfolgreicher exakter TLS-1.0-Probe deutet auf Appliance- oder Load-Balancer-Defaults. Ein SAN-Mismatch nach einer Migration bedeutet meist, dass das neue Frontend das falsche Zertifikat präsentiert. Ein gescheiterter h2-Probe beweist nur, dass h2 für dieses Angebot und diesen Handshake nicht ausgehandelt wurde; er enumeriert nicht jede ALPN-Kombination. Fehlendes HSTS auf einem DNS-Namen-HTTPS-Endpunkt ist eine separate HTTP-Policy-Lücke, keine Eigenschaft des TLS-Handshakes.
Wo die Schnellprobe endet und das Audit beginnt
Der Same-Origin-Endpunkt beschränkt Ziele auf öffentliche DNS-Namen oder global routbare IP-Literale und übliche implizite TLS-/HTTPS-Ports. Er führt vier exakte Versions-Handshakes sowie separate Default-Handshakes für präsentierte und Peer-/Hostnamen-validierte Evidenz von einem Standpunkt aus aus. Er enumeriert weder Cipher noch alle ALPN-Angebote, prüft keinen Sperrstatus und validiert nicht gegen jeden Trust-Store. Ein sauberes Ergebnis ist begrenzte Evidenz, keine Compliance-Aussage.
Häufige Fragen
Der Browser zeigt ein anderes Zertifikat als diese Probe — warum?
Meistens SNI oder Routing: Der Server wählt Zertifikate pro angefragtem Namen, und ein CDN kann diese Probe auf eine andere Edge leiten als deinen Browser. Beide Beobachtungen sind echt; der Unterschied sagt dir, dass die Zertifikatswahl vom Pfad abhängt — und das ist es wert, gewusst zu werden.
Ist akzeptiertes TLS 1.0 oder 1.1 heute noch ein echtes Problem?
Ja, als Policy- und Audit-Thema. Moderne Clients nutzen die Versionen nicht mehr, aber ihre Annahme signalisiert ungepflegte Konfiguration, reißt gängige Compliance-Baselines und lässt Downgrade-Spielräume gegen Legacy-Clients offen.
Repräsentiert der angezeigte Cipher alles, was der Server unterstützt?
Nein. Er ist nur der im gemeldeten Default-Handshake ausgehandelte Cipher. Der Checker enumeriert die Cipher-Suites des Servers nicht; ein nicht beobachteter schwacher Cipher ist weder als aktiviert noch als deaktiviert bewiesen.
Was beweist ein fehlender ALPN-Wert?
Er beweist nur, dass der gemeldete Handshake kein Anwendungsprotokoll ausgehandelt hat. Der Checker bietet h2 auf HTTPS-Port 443 getrennt unter TLS 1.2 und TLS 1.3 an; er behauptet keine Enumeration aller Protokolle, die der Server mit anderen Angeboten oder Clients aushandeln könnte.
Sollte jede Site HSTS senden?
Jede produktive HTTPS-Site sollte ein vernünftiges max-age senden. Mit includeSubDomains und besonders mit preload solltest du bewusst umgehen: Preloading ist praktisch unumkehrbar und hat schon Subdomains lahmgelegt, die still und leise noch HTTP brauchten.
Kann ich damit einen internen Host prüfen?
Nein, der Live-Endpunkt akzeptiert nur öffentliche DNS-Namen oder global routbare IP-Literale. Für interne Endpunkte hilft eine lokale Probe von einer Maschine mit Zugriff — die Lesereihenfolge bleibt dieselbe.