Handshake TLS falliti: risolvere in modo affidabile catene di certificati, SNI e rinnovo automatico con ACME

TLS è spesso „invisibile“ in esercizio – fino al momento in cui i TLS-Handshakes falliscono e improvvisamente software aziendali, portali, API o integrazioni non riescono più a stabilire connessioni. I sintomi appaiono spesso simili („Handshake failure“, „unknown ca“, „certificate verify failed“), ma non lo sono le cause: una catena di certificati incompleta, un problema di SNI (Server Name Indication, ossia la selezione del certificato corretto in base al nome host), un certificato scaduto o rinnovato in modo errato tramite ACME (Automated Certificate Management Environment, p.es. Let’s Encrypt) o un proxy che sostituisce un certificato „in transito“.

Questo contributo è strutturato come runbook per amministratori, system engineers, operatori e fornitori di servizi IT tecnici: con una sequenza di verifica chiara, check concreti, insidie tipiche, strategia di implementazione e rollback. L’obiettivo non è solo „tornare a verde“, ma uno stato stabile e verificabile – inclusi automazione e monitoring, affinché il problema non ricompaia tra quattro settimane.

Cosa avviene realmente durante il TLS-Handshake (e dove tipicamente si interrompe)

Un TLS-Handshake è la negoziazione di cifratura e identità tra client e server. Semplificando accade quanto segue: il client si connette, indica (nel caso di HTTPS consueto) tramite SNI il nome host desiderato, il server fornisce un certificato (e idealmente i certificati intermedi), entrambe le parti negoziano la versione del protocollo e la cipher-suite, e il client verifica la Chain of Trust (catena di fiducia) fino a una Root-CA nel trust store.

Punti di rottura nella pratica:

• Catena di certificati incompleta: il server fornisce solo il certificato leaf, manca l’intermediate. Alcuni client non possono „recuperarlo“ (a seconda di piattaforma/policy/offline).
• SNI non funziona: il server fornisce un certificato di default che non corrisponde all’host (CN/SAN mismatch). Comune con più vHost su una stessa IP o con load balancer.
• Rinnovo/Deployment ACME difettoso: il certificato è stato rinnovato, ma il servizio utilizza ancora il file vecchio / il binding vecchio / il keystore vecchio.
• Policy di protocollo/cipher incompatibile: client legacy non supportano TLS 1.3, oppure il server blocca TLS 1.2; ALPN (Application-Layer Protocol Negotiation) negozia HTTP/2 in modo errato.
• mTLS (Mutual TLS) / certificati client: il server si aspetta un certificato client; il client non ne invia uno o invia una CA errata.
• Tempo/CRL/OCSP: orologio di sistema errato, OCSP/CRL non raggiungibili o configurazioni „Must-Staple“.

Prima valutazione: determinare la classe di sintomo, prima di „toccare il certificato“

Prima di sostituire i certificati: inquadrare l’errore. Questo risparmia tempo e evita effetti collaterali, per esempio se un proxy causa il problema e voi intervenite sul backend.

Check 1: riguarda tutti i client o solo alcuni?

• Tutti i client colpiti: più probabilmente certificato scaduto, distribuzione di un certificato errato, SNI/certificato di default, endpoint sbagliato (DNS/load balancer).
• Solo alcune piattaforme: frequentemente problemi di catena (intermediate), trust store, vecchie policy Java o Windows, interoperabilità TLS 1.3/1.2.
• Solo client interni: proxy/inspection (TLS-Interception), distribuzione CA interna, split-DNS.

Check 2: dove termina realmente TLS? (trovare il punto di terminazione)

Nei setup moderni il TLS spesso non termina sul server applicativo vero e proprio, ma sul reverse proxy (Nginx/Apache), sul load balancer, su una WAF o su un API-Gateway. „TLS-Termination“ significa: la connessione TLS viene decifrata lì, e dietro viene eseguito HTTP o TLS nuovamente (Re-Encryption).

Conseguenza per la diagnosi: dovete testare il punto di terminazione, non „il server“. Se un Load Balancer termina, il certificato sul backend è irrilevante per il client esterno.

Passaggi di verifica con OpenSSL e acquisizione sistematica delle evidenze

La risposta più rapida e attendibile si ottiene in genere con openssl s_client. Importante: testare sempre con il nome host previsto (SNI), altrimenti potreste vedere il certificato di default.

Verificare SNI e la catena dei certificati in un unico passaggio

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

A cosa prestare attenzione nell’output:

• subject / SAN: il nome host è presente nelle Subject Alternative Names (SAN)? Il CN da solo non è più sufficiente per i client moderni.
• issuer: chi ha firmato? CA/Intermediate attesi?
• Verify return code: „0 (ok)“ è corretto; codici come „unable to get local issuer certificate“ indicano problemi di catena.
• Certificate chain: sono inclusi il leaf e gli intermediate? La root tipicamente non deve essere inviata.
• OCSP response: se viene usato lo stapling dovrebbe arrivare una response; in caso di errore spesso si vedono Timeouts/„no response“.

Testare ALPN e la versione del protocollo (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

Perché è utile: alcuni errori si manifestano solo in percorsi di negoziazione specifici, p.es. se un proxy annuncia HTTP/2 (h2) ma lo mappa internamente in modo errato, o se appliance più datate non supportano TLS 1.3 correttamente.

Causa frequente 1: catena dei certificati incompleta (manca l’intermediate)

Una catena di certificati è composta dal certificato Leaf (per il vostro host), da uno o più certificati Intermediate (intermedi) e da una Root-CA che risiede nel trust store del client. Se il server non invia i certificati Intermediate, alcuni client potrebbero non riuscire a completare la catena — soprattutto in ambienti RESTrittivi senza accesso agli URL AIA o con proxy che bloccano.

Sintomi tipici

• Il Browser A funziona, il Browser B o un client Java-/Windows fallisce.
• Messaggi di errore: „unable to get local issuer certificate“, „unknown ca“, „self signed certificate in certificate chain“ (fuorvianti, spesso indicano un problema di catena).
• Solo determinate middlebox / client MTLS sono interessati.

Come verificare correttamente la catena

Oltre a s_client conviene una seconda verifica: estraete i certificati e controllate se la catena termina su una Root nota.

# 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 pratica la soluzione è spesso banale ma cruciale: al TLS-endpoint deve essere configurata una Fullchain (Leaf + Intermediate), non solo il certificato leaf. Nei client ACME il file si chiama spesso fullchain.pem (non cert.pem).

Insidie operative

• File sbagliato collegato: Nginx/Apache punta a cert.pem invece di fullchain.pem.
• Load balancer ‚dimentica‘ l’intermediate: a seconda del prodotto la chain deve essere importata separatamente o non viene trasferita correttamente durante l’upload.
• Formati dei keystore: Java (JKS/PKCS12) e Windows (store dei certificati) spesso si aspettano l’import comprensivo della chain, altrimenti il leaf RESTa „孤“.

Causa comune 2: errata configurazione SNI e certificati predefiniti

SNI (Server Name Indication) è un’estensione TLS con cui il client comunica il nome host durante l’handshake. Il server può così selezionare il certificato corretto quando più domini condividono la stessa combinazione IP/porta.

Sintomi tipici

• L’accesso tramite IP non funziona o RESTituisce un certificato errato (atteso); anche l’accesso tramite DNS può fornire un certificato ’sbagliato‘.
• Un host sulla stessa IP funziona, un altro no.
• Solo client più vecchi falliscono (senza supporto SNI), per esempio sistemi embedded molto datati.

Verificare che venga effettivamente consegnato il certificato corretto

# 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

Se con „ohne SNI“ arriva un certificato diverso, è normale. Se con „mit SNI“ arriva comunque il certificato sbagliato, la causa è nel punto di terminazione: vHost-Mapping, Listener-Zuordnung, binding errato o un dispositivo a monte che ha già concluso il TLS-Handshake.

Rischio: Legacy-Clients senza SNI

Se avete ancora client senza SNI sul campo, vi serve una strategia: IP/porta dedicata per quel dominio, oppure un endpoint legacy separato. In ambienti B2B questo si riscontra, per esempio, su appliance datate, gateway di stampa/scan o gateway embedded in produzione.

Cause comune 3: rinnovo automatico con ACME – il certificato è rinnovato ma non attivo

ACME automatizza la richiesta e il rinnovo. Il rischio operativo reale spesso non riguarda il rinnovo, ma il deployment: il certificato è rinnovato sul disco, ma il servizio usa ancora il certificato vecchio perché manca un Reload/RESTart o è stato associato un percorso errato.

Comprendere la validazione ACME: HTTP-01, DNS-01, TLS-ALPN-01

• HTTP-01: il server ACME richiede un file token via HTTP (porta 80). Fallisce in presenza di redirect policy, regole WAF o assenza di apertura inbound.
• DNS-01: token come record DNS-TXT. Buono per certificati wildcard e quando la porta 80 non è disponibile, ma dipende dall’automazione/propagazione DNS.
• TLS-ALPN-01: validazione tramite porta 443 e ALPN. Utile se la porta 80 non è aperta, ma può entrare in conflitto con alcuni proxy/terminator.

Verificare che il nuovo certificato sia effettivamente attivo

Confrontate la data NotAfter (scadenza) e idealmente anche il fingerprint del certificato in uso con l’artefatto atteso.

# 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

Se il certificato live è vecchio nonostante i file ACME siano nuovi, si tratta di un problema di deployment/Reload.

Insidie tipiche di ACME nell’operatività

• Reload mancante: il servizio legge i certificati solo all’avvio. Soluzione: Reload pianificato dopo il rinnovo avvenuto con successo.
• Più istanze: il certificato viene rinnovato sul nodo A ma il traffico passa per il nodo B. Soluzione: storage centrale, gestione configurazioni o distribuzione tramite hook.
• Container/deployment immutabili: il certificato risiede sull’host, il container non lo vede (manca il volume) oppure l’ingress controller lo gestisce separatamente.
• Permessi file/SELinux/AppArmor: il rinnovo scrive un nuovo file e il servizio poi non riesce a leggerlo.
• Clock Skew: discrepanze temporali causano „not yet valid“ o controlli OCSP fragili.

Automazione ACME robusta: Hooks, Reload und Idempotenz

Indipendentemente dall’ACME-Client (certbot, acme.sh, win-acme ecc.) si è dimostrato efficace un pattern: dopo un rinnovo riuscito eseguire un deploy-hook che (1) disponga file/bundle in modo consistente, (2) imposti i permessi, (3) esegua un reload controllato e (4) avvii un smoke-test.

# 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"

Il hook in sé dovrebbe essere „idempotent“ (eseguibile più volte senza effetti collaterali) e RESTituire codici di exit chiari, affinché il monitoring/i job possano segnalare in modo affidabile.

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

Bei mTLS (mutual TLS) non si autentica solo il server verso il client, ma anche il client verso il server tramite un certificato client. Questo è comune in integrazioni interne, connessioni B2B con partner o endpoint di amministrazione.

Typische Symptome

• Il handshake fallisce con „handshake failure“ o „bad certificate“.
• I log del server mostrano: „no required SSL certificate was sent“ o „unknown ca“ (riferito alla Client-CA).

Prüfpfad

• Il endpoint richiede effettivamente mTLS (Policy/Location/Listener)?
• La CA che rilascia i certificati client è configurata sul server come attendibile?
• EKU/Key Usage (Extended Key Usage: „Client Authentication“) nel certificato client è corretto?
• SNI/Host è mappato correttamente sulla policy mTLS (non accidentalmente su un listener „public“)?

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

Molte interruzioni TLS avvengono dopo misure di hardening: disabilitazione di TLS 1.0/1.1 (spesso corretta), liste di cipher RESTrittive, forzatura di TLS 1.3 o selezione rigorosa delle curve. Questo non è un argomento contro l’hardening, ma a favore di una transizione controllata con punti di misura.

Praxisregel: Erst messen, dann schalten

• Quali client sono connessi (browser, Java, .NET, Appliances, partner)?
• Quali protocolli vengono effettivamente utilizzati (TLS 1.2/1.3)?
• Esistono requisiti di compliance che già richiedono TLS 1.2+?

In situazioni di troubleshooting aiuta un temporaneo allentamento per circoscrivere la causa. Importante: solo con finestra di change, documentato e con chiara procedura di rollback.

Prüfcheckliste: In 20 Minuten zur wahrscheinlichsten Ursache

Se siete sotto pressione temporale, utilizzate quest’ordine. Minimizza il lavoro ripetitivo e fornisce rapidamente prove utilizzabili.

1. Determinare il punto di terminazione: DNS → Load Balancer → WAF → Reverse Proxy → App. Testare lì.
2. Prelevare il certificato live (con SNI): SAN, Issuer, NotAfter, Fingerprint.
3. Controllare la catena di certificazione: viene consegnata la fullchain? Esaminare il codice di verifica.
4. Test SNI A/B: confrontare con e senza -servername.
5. Verificare le versioni TLS: forzare tls1_2 / tls1_3, testare ALPN.
6. Chiarire mTLS: il server si aspetta un certificato client?
7. Controllare lo stato ACME: Renewal-Logs, ultimo rinnovo riuscito, Hook/Reload eseguiti?

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

I problemi TLS raramente sono „una tantum“. Senza misure operative si ripresenteranno: al prossimo cambio di intermediate, al prossimo rollover dei certificati, al prossimo aggiornamento del load balancer o quando un nodo del cluster viene ricostruito.

1) Monitoring auf Ablauf und auf echten Handshake

Non basta monitorare solo la data di scadenza. Volete almeno due segnali:

• Scadenza del certificato: NotAfter entro una soglia (es. 14/7/3 giorni).
• Handshake reale dall’esterno: SNI corretto, Chain valida, versione TLS ok. Questo copre problemi di SNI/Chain/Deployment.

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

Un rollback pragmatico significa: poter tornare, nel giro di pochi minuti, al certificato/binding precedente. Per questo sono necessari:

• Archivio versionato degli artefatti di certificato (almeno la versione precedente), con protezione degli accessi.
• Percorsi/Bindings documentati per ogni servizio (z. B. Nginx-Config, IIS-Binding, Load-Balancer-Listener).
• Un processo definito di reload/RESTart e un smoke-test (Handshake + stato HTTP + ggf. chiamata API).

3) ACME sauber in Multi-Node-Setups betreiben

In ambienti HA la distribuzione è determinante. Schemi robusti tipici:

• Gestione centrale dei certificati al punto di terminazione: ACME gira direttamente sul Load Balancer/Reverse Proxy, non “da qualche parte” nel backend.
• Pull statt Push: i nodi prelevano periodicamente il certificato da uno store protetto (Secrets-Management) ed eseguono un reload controllato.
• Hooks mit Health-Gate: effettuare il commit del deploy solo quando il nuovo handshake sul listener di destinazione è riuscito.

Rückfallstrategie im Incident: Stabilisieren, dann verbessern

Quando le interfacce di produzione cadono, conta la sequenza:

• Stabilizzare: fornire il certificato corretto con catena valida; se necessario tornare temporaneamente a una policy nota e funzionante (consentire TLS 1.2, baseline di cipher pulita).
• Verificare: testare da più reti/client (interno/esterno), documentare i test SNI, registrare i fingerprint.
• Risolvere la causa: ACME-Deployment, fullchain errata, mappatura SNI sbagliata, distribuzione nel cluster.
• Raffinare: irrigidire nuovamente la Security-Policy, ma con punti di misurazione e rollback.

È importante non limitare il “fix” al solo sintomo. Se, ad esempio, il rinnovo sul Node A funziona ma il Node B continua a servire il certificato vecchio, non si tratta di un problema del certificato, ma di un problema di distribuzione e operatività.

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

Quando gli handshake TLS falliscono, il pericolo maggiore non è la crittografia, ma la complessità operativa: più punti di terminazione, mappatura SNI, catene di certificati, automazione e meccaniche di reload. Con una sequenza di verifica fissa (Terminierungspunkt → Live-Zertifikat mit SNI → Chain → Protokolle/ALPN → ACME-Deployment) si arriva rapidamente alla causa. La sostenibilità arriva con misure operative: monitoring degli handshake, artefatti di certificato versionati, hook controllati e una via di rollback praticata.

Per questo tema sono importanti anche le configurazioni errate di SNI e il rinnovo automatico ACME. Il contributo inquadra questi aspetti in modo comprensibile e mostra a cosa pRESTare attenzione nella pratica.