TLS-Troubleshooting von außen: Zertifikate, Namen und Handshakes

Beginne bei dem, was der Server wirklich präsentiert hat

TLS-Fehler kommen in Schichten, und der schnellste Weg prüft sie der Reihe nach: Name, Gültigkeit, Kette, Protokoll. Sondiere den Endpunkt mit dem TLS-Konfigurationsprüfung und lies zuerst den Namensabgleich — das präsentierte Zertifikat muss exakt den angefragten Host abdecken, über SAN-Einträge, nicht über den Common Name, den Clients seit Jahren nicht mehr honorieren. Danach die Gültigkeitsdaten, dann die Frage, ob ausgehandeltes Protokoll und akzeptierte Legacy-Versionen nach gepflegter Konfiguration aussehen.

Sondiere per Hostname, nie per IP. Moderne Server wählen ihr Zertifikat anhand des SNI-Werts im Handshake; eine IP-Probe zeigt das Zertifikat des Default-Virtual-Hosts — das von dem, was Browser bekommen, komplett abweichen kann. Dieses eine Detail erklärt eine ganze Familie von Geister-Vorfällen: das Monitoring-System, das per IP sondiert und über ein Zertifikat alarmiert, das kein Nutzer je gesehen hat.

Die Mismatch-Muster und was sie bedeuten

Ein Zertifikat mit falschem Namen unmittelbar nach einer Migration heißt: Das neue Frontend, der Load Balancer oder die CDN-Edge hat das richtige Zertifikat nie bekommen — der DNS-Cutover hat funktioniert, das Zertifikats-Deployment nicht. Ein Zertifikat für die Default-Domain eines Hosters heißt: SNI-Routing kaputt oder Vhost-Zuordnung hat deinen Namen verloren. Und ein Zertifikat, das sich zwischen deiner Probe und dem Browser eines Nutzers unterscheidet, heißt meist: Ein CDN bedient Edges unterschiedlich, oder eine Middlebox hängt dazwischen — beides will man präzise wissen.

Kettenprobleme erzeugen den klassischen Hier-geht's-dort-nicht-Split. Browser reparieren unvollständige Ketten, indem sie fehlende Intermediates nachladen oder gecachte verwenden; strenge API-Clients, ältere Java-Stacks und Embedded-Geräte tun das nicht. Wenn curl scheitert, während Browser durchkommen: Verdacht zuerst auf ein fehlendes Intermediate. Dekodiere die präsentierte Kette mit dem SSL-Zertifikat-Decoder — Aussteller, SAN-Abdeckung und Kettenreihenfolge, ohne den Browser zu verlassen.

Schlüsselrotation hat einen leiseren Wirkungsradius: Alles, was Schlüssel pinnt, merkt es, wenn Renewals das Schlüsselpaar wechseln. HPKP ist tot, aber DANE/TLSA-Bindungen und Certificate-Pinning in Mobile-Apps sind quicklebendig — ein Renewal mit Schlüsselwechsel kann die Mail-Zustellung DANE-validierender Sender brechen, während jeder Browser grün bleibt. Existieren TLSA-Records für den Host, müssen Renewals und Schlüsselwechsel mit ihnen koordiniert werden — nicht nur mit dem Zertifikatskalender.

Über dem Handshake: die Header-Schicht

Ein Teil dessen, was nach TLS-Ärger aussieht, wohnt eine Schicht höher. Fehlendes ALPN kostet still HTTP/2 und zeigt sich als Langsamkeit, nicht als Fehler. HSTS entscheidet, ob eine heruntergestufte Erstverbindung überhaupt möglich ist — sein Fehlen ist eine Policy-Lücke, die keine Handshake-Probe als Fehler markiert. Mixed-Content-Warnungen nach einer HTTPS-Migration sind Inhaltsreferenzen, keine Zertifikatsprobleme. Lies die Response-Header systematisch mit dem HTTP-Header-Analyzer, wenn der Handshake selbst sauber ist.

Und wenn Redirects im Spiel sind — HTTP auf HTTPS, Apex auf www, alte Domain auf neue —, geh die Kette explizit ab mit dem Redirect-/Canonical-/Indexierbarkeitsprüfung: Jeder Hop ist ein eigener TLS-Endpunkt mit eigenem Zertifikat, und der Vorfall sitzt oft auf Hop zwei einer Kette, deren Existenz alle vergessen haben. Eine saubere externe Diagnose benennt die scheiternde Schicht präzise — Name, Kette, Protokoll oder die Policy darüber — und dieser eine Satz ist der größte Teil der Behebung.