TLS-Handshakes schlagen fehl: Zertifikatsketten, SNI und automatische Erneuerung mit ACME zuverlässig beheben

TLS ist im Betrieb oft „unsichtbar“ – bis der Moment kommt, in dem TLS-Handshakes schlagen fehl und plötzlich Business-Software, Portale, APIs oder Integrationen keine Verbindungen mehr aufbauen können. Die Symptome wirken dabei häufig ähnlich („Handshake failure“, „unknown ca“, „certificate verify failed“), die Ursachen sind es nicht: eine unvollständige Zertifikatskette, ein SNI-Problem (Server Name Indication, also die Auswahl des passenden Zertifikats anhand des Hostnamens), ein abgelaufenes oder falsch erneuertes Zertifikat über ACME (Automated Certificate Management Environment, z. B. Let’s Encrypt) oder ein Proxy, der ein Zertifikat „unterwegs“ ersetzt.

Dieser Beitrag ist als Runbook für Administratoren, System Engineers, Operatoren und technische IT-Dienstleister aufgebaut: mit klarer Prüfreihenfolge, konkreten Checks, typischen Stolperfallen, Umsetzungs- und Rückfallstrategie. Ziel ist nicht nur „wieder grün“, sondern ein stabiler, überprüfbarer Zustand – inklusive Automatisierung und Monitoring, damit das Problem nicht in vier Wochen wiederkehrt.

Was beim TLS-Handshake wirklich passiert (und wo es typischerweise bricht)

Ein TLS-Handshake ist die Aushandlung von Verschlüsselung und Identität zwischen Client und Server. Vereinfacht passiert Folgendes: Der Client verbindet sich, nennt (bei HTTPS üblich) per SNI den gewünschten Hostnamen, der Server liefert ein Zertifikat (und idealerweise die Zwischenzertifikate), beide handeln Protokollversion und Cipher-Suite aus, und der Client prüft die Chain of Trust (Vertrauenskette) bis zu einer Root-CA im Trust Store.

Bruchstellen in der Praxis:

• Zertifikatskette unvollständig: Server liefert nur Leaf-Zertifikat, Intermediate fehlt. Manche Clients können das nicht „nachladen“ (je nach Plattform/Policy/Offline).
• SNI greift nicht: Server liefert ein Default-Zertifikat, das nicht zum Host passt (CN/SAN mismatch). Häufig bei mehreren vHosts auf einer IP oder bei Load Balancern.
• ACME-Erneuerung/Deployment fehlerhaft: Zertifikat wurde zwar erneuert, aber der Dienst nutzt noch die alte Datei / das alte Binding / den alten Keystore.
• Protokoll-/Cipher-Policy inkompatibel: Legacy-Clients können TLS 1.3 nicht, oder Server blockiert TLS 1.2; ALPN (Application-Layer Protocol Negotiation) verhandelt HTTP/2 falsch.
• mTLS (Mutual TLS) / Client-Zertifikate: Server erwartet ein Client-Zertifikat, Client liefert keines oder falsche CA.
• Zeit/CRL/OCSP: Falsche Systemzeit, OCSP/CRL nicht erreichbar oder „Must-Staple“-Konstellationen.

Ersteinschätzung: Symptomklasse bestimmen, bevor Sie „am Zertifikat drehen“

Bevor Sie Zertifikate tauschen: ordnen Sie den Fehler ein. Das spart Zeit und verhindert Nebenwirkungen, etwa wenn ein Proxy das Problem verursacht und Sie am Backend drehen.

Check 1: Betrifft es alle Clients oder nur bestimmte?

• Alle Clients betroffen: eher Zertifikat abgelaufen, falsches Zertifikat ausgerollt, SNI/Default-Zertifikat, falscher Endpoint (DNS/Load Balancer).
• Nur bestimmte Plattformen: häufig Chain-Issues (Intermediate), Trust Store, alte Java- oder Windows-Policies, TLS 1.3/1.2-Interoperabilität.
• Nur interne Clients: Proxy/Inspection (TLS-Interception), interne CA-Verteilung, Split-DNS.

Check 2: Wo endet TLS wirklich? (Terminierungspunkt finden)

In modernen Setups endet TLS oft nicht am eigentlichen Applikationsserver, sondern am Reverse Proxy (Nginx/Apache), am Load Balancer, an einer WAF oder an einem API-Gateway. „TLS-Termination“ bedeutet: dort wird die TLS-Verbindung entschlüsselt, und dahinter läuft HTTP oder TLS neu (Re-Encryption).

Konsequenz für die Fehlersuche: Sie müssen den Terminierungspunkt testen, nicht „den Server“. Wenn ein Load Balancer terminiert, ist das Zertifikat am Backend irrelevant für den externen Client.

Prüfschritte mit OpenSSL und systematischer Beweissicherung

Die schnellste belastbare Aussage bekommen Sie meist mit openssl s_client. Wichtig: immer mit dem erwarteten Hostnamen testen (SNI), sonst sehen Sie eventuell das Default-Zertifikat.

SNI und Zertifikatskette in einem Schritt prüfen

# SNI explizit setzen, Zertifikatskette anzeigen, OCSP-Informationen anfordern
openssl s_client 
  -connect example.com:443 
  -servername example.com 
  -showcerts 
  -status 
  </dev/null

Worauf Sie in der Ausgabe achten:

• subject / SAN: passt der Hostname in die Subject Alternative Names (SAN)? CN allein reicht bei modernen Clients nicht mehr.
• issuer: wer hat signiert? Erwartete CA/Intermediate?
• Verify return code: „0 (ok)“ ist gut; Codes wie „unable to get local issuer certificate“ deuten auf Kettenprobleme.
• Certificate chain: sind Leaf + Intermediate(s) enthalten? Root muss typischerweise nicht mitgesendet werden.
• OCSP response: wenn Stapling genutzt wird, sollte eine Response kommen; bei Fehlern sehen Sie oft Timeouts/„no response“.

ALPN und Protokollversion testen (TLS 1.2 vs TLS 1.3)

# TLS 1.2 erzwingen
openssl s_client -connect example.com:443 -servername example.com -tls1_2 </dev/null

# TLS 1.3 erzwingen
openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null

# ALPN-Angebot simulieren (z. B. HTTP/2 und HTTP/1.1)
openssl s_client -connect example.com:443 -servername example.com -alpn "h2,http/1.1" </dev/null

Warum das hilft: Einige Fehler erscheinen nur bei bestimmten Negotiation-Pfaden, z. B. wenn ein Proxy HTTP/2 (h2) ankündigt, aber intern falsch mapped, oder wenn ältere Appliances TLS 1.3 nicht sauber unterstützen.

Häufige Ursache 1: Unvollständige Zertifikatskette (Intermediate fehlt)

Eine Zertifikatskette besteht aus Leaf-Zertifikat (für Ihren Host), einem oder mehreren Intermediate-Zertifikaten (Zwischenzertifikate) und einer Root-CA, die im Trust Store des Clients steckt. Wenn der Server die Intermediate-Zertifikate nicht mitsendet, können manche Clients die Kette nicht vervollständigen – besonders in restriktiven Umgebungen ohne Zugriff auf AIA-URLs oder mit Proxy-Blocking.

Typische Symptome

• Browser A funktioniert, Browser B oder ein Java-/Windows-Client schlägt fehl.
• Fehlertexte: „unable to get local issuer certificate“, „unknown ca“, „self signed certificate in certificate chain“ (missverständlich, oft Kettenproblem).
• Nur bestimmte Middleboxes/MTLS-Clients betroffen.

So prüfen Sie die Kette sauber

Neben s_client lohnt eine zweite Sicht: extrahieren Sie die Zertifikate und prüfen Sie, ob die Kette bis zu einer bekannten Root schließt.

# Zertifikate aus der s_client-Ausgabe in Dateien schreiben (manuell oder via Skript)
# Danach: Prüfen, ob Leaf gegen eine angegebene Chain verifizierbar ist
openssl verify -CAfile root-and-intermediate.pem leaf.pem

In der Praxis ist die Lösung meist banal, aber entscheidend: am TLS-Endpunkt muss eine Fullchain konfiguriert sein (Leaf + Intermediate), nicht nur das Leaf-Zertifikat. Bei ACME-Clients heißt die Datei oft fullchain.pem (nicht cert.pem).

Stolperfallen im Betrieb

• Falsche Datei gebunden: Nginx/Apache zeigt auf cert.pem statt fullchain.pem.
• Load Balancer „verschluckt“ Intermediate: je nach Produkt muss Chain separat importiert werden oder wird beim Upload nicht korrekt übernommen.
• Keystore-Formate: Java (JKS/PKCS12) und Windows (Zertifikatsspeicher) erwarten oft Import inkl. Chain, sonst ist das Leaf „孤“.

Häufige Ursache 2: SNI-Fehlkonfiguration und Default-Zertifikate

SNI (Server Name Indication) ist eine TLS-Erweiterung, mit der der Client schon beim Verbindungsaufbau den Hostnamen nennt. Der Server kann dann das passende Zertifikat auswählen, wenn mehrere Domains auf derselben IP/Port-Kombination liegen.

Typische Symptome

• Aufruf per IP funktioniert nicht oder liefert falsches Zertifikat (erwartbar), aber auch Aufruf per DNS liefert „falsches“ Zertifikat.
• Ein Host unter derselben IP funktioniert, ein anderer nicht.
• Nur ältere Clients scheitern (ohne SNI-Unterstützung), z. B. sehr alte Embedded-Systeme.

Prüfen, ob wirklich das richtige Zertifikat ausgeliefert wird

# Ohne SNI testen: Server wird Default-Zertifikat liefern
openssl s_client -connect example.com:443 -showcerts </dev/null

# Mit SNI testen: korrektes vHost-Zertifikat erwartet
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

Wenn „ohne SNI“ ein anderes Zertifikat kommt, ist das normal. Wenn „mit SNI“ trotzdem das falsche Zertifikat kommt, liegt die Ursache am Terminierungspunkt: vHost-Mapping, Listener-Zuordnung, falsches Binding oder ein vorgelagertes Gerät, das den TLS-Handshake bereits beendet.

Risiko: Legacy-Clients ohne SNI

Wenn Sie noch Clients ohne SNI im Feld haben, brauchen Sie eine Strategie: dedizierte IP/Port für diese Domain, oder ein separates Legacy-Endpoint. In B2B-Umgebungen taucht das z. B. bei alten Appliances, Druck-/Scan-Gateways oder Embedded-Gateways in Produktion auf.

Häufige Ursache 3: Automatische Erneuerung mit ACME – Zertifikat ist erneuert, aber nicht aktiv

ACME automatisiert Beantragung und Erneuerung. Das eigentliche Betriebsrisiko liegt oft nicht in der Erneuerung, sondern im Deployment: Das Zertifikat ist auf Disk erneuert, aber der Dienst nutzt noch das alte Zertifikat, weil ein Reload/Restart fehlt oder ein falscher Pfad gebunden ist.

ACME-Validierung verstehen: HTTP-01, DNS-01, TLS-ALPN-01

• HTTP-01: ACME-Server ruft eine Token-Datei per HTTP (Port 80) ab. Scheitert bei Redirect-Policies, WAF-Regeln, fehlender Inbound-Freigabe.
• DNS-01: Token als DNS-TXT-Record. Gut für Wildcard-Zertifikate und wenn Port 80 nicht möglich ist, aber abhängig von DNS-Automation/Propagation.
• TLS-ALPN-01: Validierung über Port 443 und ALPN. Praktisch, wenn Port 80 nicht offen ist, kann aber mit bestimmten Proxies/Terminatoren kollidieren.

Prüfen, ob das neue Zertifikat wirklich aktiv ist

Vergleichen Sie das NotAfter-Datum (Ablauf) und idealerweise auch den Fingerprint des Live-Zertifikats mit dem erwarteten Artefakt.

# Live-Zertifikat holen und Ablaufdatum anzeigen
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null 
  | openssl x509 -noout -dates -subject -issuer -fingerprint -sha256

Wenn das Live-Zertifikat alt ist, obwohl die ACME-Dateien neu sind, ist es ein Deployment-/Reload-Problem.

Typische Stolperfallen bei ACME im Alltag

• Reload fehlt: Dienst liest Zertifikate nur beim Start. Lösung: geplanter Reload nach erfolgreicher Erneuerung.
• Mehrere Instanzen: Zertifikat wird auf Node A erneuert, Traffic geht aber über Node B. Lösung: zentraler Storage, Konfig-Management, oder per Hook verteilen.
• Container/Immutable Deployments: Zertifikat liegt im Host, Container sieht es nicht (Volume fehlt) oder Ingress-Controller verwaltet es getrennt.
• Dateirechte/SELinux/AppArmor: Erneuerung schreibt neue Datei, Dienst kann sie danach nicht lesen.
• Clock Skew: Zeitabweichungen führen zu „not yet valid“ oder fragilen OCSP-Checks.

Robuste ACME-Automation: Hooks, Reload und Idempotenz

Unabhängig vom ACME-Client (certbot, acme.sh, win-acme etc.) bewährt sich ein Pattern: Nach erfolgreicher Erneuerung ein deploy-hook, der (1) Dateien/Bundles konsistent bereitstellt, (2) Berechtigungen setzt, (3) einen kontrollierten Reload ausführt und (4) einen Smoke-Test startet.

# Beispiel: certbot mit deploy-hook (Linux)
# Der Hook läuft nur, wenn wirklich erneuert wurde.
certbot renew 
  --deploy-hook "/usr/local/sbin/tls-deploy-and-reload.sh"

Der Hook selbst sollte „idempotent“ sein (mehrfach ausführbar ohne Seiteneffekte) und klare Exit-Codes liefern, damit Monitoring/Jobs zuverlässig alarmieren können.

mTLS und Client-Zertifikate: Wenn der Server den Client ablehnt

Bei mTLS (mutual TLS) authentifiziert sich nicht nur der Server gegenüber dem Client, sondern auch der Client gegenüber dem Server mit einem Client-Zertifikat. Das ist in internen Integrationen, B2B-Partneranbindungen oder Admin-Endpunkten verbreitet.

Typische Symptome

• Handshake bricht mit „handshake failure“ oder „bad certificate“ ab.
• Server-Logs zeigen: „no required SSL certificate was sent“ oder „unknown ca“ (bezogen auf Client-CA).

Prüfpfad

• Verlangt der Endpoint wirklich mTLS (Policy/Location/Listener)?
• Ist die CA, die Client-Zertifikate ausstellt, auf dem Server als vertrauenswürdig konfiguriert?
• Passt EKU/Key Usage (Extended Key Usage: „Client Authentication“) im Client-Zertifikat?
• Wird SNI/Host korrekt auf die mTLS-Policy gemappt (nicht versehentlich auf „public“ Listener)?

Protokoll- und Cipher-Policy: Wenn Security-Härtung unerwartet Clients aussperrt

Viele TLS-Ausfälle entstehen nach Härtungsmaßnahmen: Deaktivierung von TLS 1.0/1.1 (meist richtig), restriktive Cipher-Listen, erzwungenes TLS 1.3 oder strikte Kurvenauswahl. Das ist kein Argument gegen Härtung – aber für eine kontrollierte Umstellung mit Messpunkten.

Praxisregel: Erst messen, dann schalten

• Welche Clients hängen dran (Browser, Java, .NET, Appliances, Partner)?
• Welche Protokolle werden tatsächlich genutzt (TLS 1.2/1.3)?
• Gibt es Compliance-Vorgaben, die ohnehin TLS 1.2+ verlangen?

In Troubleshooting-Situationen hilft eine temporäre Entschärfung, um Ursache einzugrenzen. Wichtig: nur mit Change-Fenster, dokumentiert, und mit klarer Rücknahme.

Prüfcheckliste: In 20 Minuten zur wahrscheinlichsten Ursache

Wenn Sie unter Zeitdruck sind, nutzen Sie diese Reihenfolge. Sie minimiert „Ratearbeit“ und liefert schnell verwertbare Beweise.

1. Terminierungspunkt bestimmen: DNS → Load Balancer → WAF → Reverse Proxy → App. Dort testen.
2. Live-Zertifikat ziehen (mit SNI): SAN, Issuer, NotAfter, Fingerprint.
3. Zertifikatskette prüfen: wird fullchain ausgeliefert? Verify-Code ansehen.
4. SNI-A/B-Test: mit und ohne -servername vergleichen.
5. TLS-Versionen prüfen: tls1_2 / tls1_3 erzwingen, ALPN testen.
6. mTLS klären: erwartet der Server ein Client-Zertifikat?
7. ACME-Status prüfen: Renewal-Logs, letzte erfolgreiche Erneuerung, Hook/Reload gelaufen?

Umsetzung: Saubere Betriebsmaßnahmen, damit es nicht wieder passiert

TLS-Probleme sind selten „einmalig“. Ohne Betriebsmaßnahmen kommen sie wieder: beim nächsten Intermediate-Wechsel, beim nächsten Zertifikats-Rollover, beim nächsten Load-Balancer-Update oder wenn ein Node aus dem Cluster neu aufgebaut wird.

1) Monitoring auf Ablauf und auf echten Handshake

Nur das Ablaufdatum zu überwachen ist zu wenig. Sie wollen mindestens zwei Signale:

• Zertifikatsablauf: NotAfter innerhalb eines Schwellenwerts (z. B. 14/7/3 Tage).
• Echter Handshake von außen: SNI korrekt, Chain valide, TLS-Version ok. Das deckt SNI-/Chain-/Deployment-Probleme ab.

2) Change- und Rollback-Plan für Zertifikate

Ein pragmatischer Rollback heißt: Sie können innerhalb weniger Minuten auf das vorherige Zertifikat/Binding zurück. Dafür brauchen Sie:

• Versionierte Ablage der Zertifikatsartefakte (mindestens vorherige Version), mit Zugriffsschutz.
• Dokumentierte Pfade/Bindings je Dienst (z. B. Nginx-Config, IIS-Binding, Load-Balancer-Listener).
• Einen definierten Reload/Restart-Prozess und einen Smoke-Test (Handshake + HTTP-Status + ggf. API-Call).

3) ACME sauber in Multi-Node-Setups betreiben

In HA-Umgebungen entscheidet die Verteilung. Typische robuste Muster:

• Zentrales Zertifikats-Management am Terminierungspunkt: ACME läuft direkt auf dem Load Balancer/Reverse Proxy, nicht „irgendwo“ im Backend.
• Pull statt Push: Nodes holen das Zertifikat periodisch aus einem gesicherten Store (Secrets-Management) und reloaden kontrolliert.
• Hooks mit Health-Gate: Deploy erst „committen“, wenn der neue Handshake auf dem Ziel-Listener erfolgreich ist.

Rückfallstrategie im Incident: Stabilisieren, dann verbessern

Wenn produktive Schnittstellen ausfallen, zählt Reihenfolge:

• Stabilisieren: korrektes Zertifikat mit gültiger Kette ausliefern, notfalls temporär auf eine bekannte, funktionierende Policy zurück (TLS 1.2 erlauben, saubere Cipher-Baseline).
• Verifizieren: von mehreren Netzen/Clients testen (intern/extern), SNI-Tests dokumentieren, Fingerprints festhalten.
• Ursache beheben: ACME-Deployment, falsche fullchain, falsches SNI-Mapping, Cluster-Verteilung.
• Nachschärfen: Security-Policy wieder härten, aber mit Messpunkten und Rollback.

Wichtig ist, dass Sie den „Fix“ nicht nur am Symptom festmachen. Wenn z. B. die Erneuerung am Node A klappt, aber Node B weiterhin das alte Zertifikat ausliefert, ist das kein Zertifikatsproblem, sondern ein Verteilungs- und Betriebsproblem.

Fazit: TLS-Handshakes schlagen fehl – aber die Ursachen sind mit einem klaren Runbook gut beherrschbar

Wenn TLS-Handshakes scheitern, ist die größte Gefahr nicht die Kryptografie, sondern die Komplexität im Betrieb: mehrere Terminierungspunkte, SNI-Mapping, Zertifikatsketten, Automatisierung und Reload-Mechanik. Mit einer festen Prüfreihenfolge (Terminierungspunkt → Live-Zertifikat mit SNI → Chain → Protokolle/ALPN → ACME-Deployment) kommen Sie schnell zur Ursache. Nachhaltig wird es erst mit Betriebsmaßnahmen: Handshake-Monitoring, versionierte Zertifikatsartefakte, kontrollierte Hooks und ein geübter Rollback-Pfad.

Für dieses Thema sind auch Sni Fehlkonfiguration und Acme Automatische Erneuerung wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.