TLS: verifiche rapide su certificati, catena e scadenza

Quando un sito “sembra” irraggiungibile

Molti problemi di sicurezza e disponibilità non nascono da un attacco, ma da un errore TLS: certificato scaduto, catena incompleta, hostname non coerente o data del server fuori sync. Il risultato è spesso un blocco silenzioso nel browser, un errore lato API o un client che rifiuta la connessione.

La buona notizia è che puoi isolare la causa in pochi minuti con controlli mirati, senza toccare subito configurazioni complesse.

1. Verifica la scadenza del certificato

Il primo controllo è sempre la data di validità. Un certificato scaduto interrompe il traffico in modo netto e può colpire solo alcuni endpoint se il bilanciatore o il reverse proxy gestisce più virtual host.

openssl x509 -in cert.pem -noout -dates

Se lavori da remoto, puoi controllare anche il certificato esposto dal servizio:

openssl s_client -connect esempio.it:443 -servername esempio.it 

Osserva in particolare:

• notBefore e notAfter
• eventuali certificati diversi tra ambienti
• rinnovi automatici falliti o non applicati

2. Controlla la catena di certificazione

Un certificato valido può comunque fallire se la catena intermedia non è completa. Questo accade spesso dopo un rinnovo, quando il server non invia tutti i certificati intermedi richiesti.

Nel comando openssl s_client, cerca errori come unable to verify the first certificate o verify return code diverso da 0.

Un certificato corretto ma con chain incompleta può sembrare “rotto” solo su alcuni client, soprattutto quelli più rigidi o meno aggiornati.

Se usi un reverse proxy, verifica che il file configurato includa il full chain e non solo il certificato leaf.

3. Verifica hostname e SAN

Molti errori TLS non dipendono dal certificato in sé, ma dal nome richiesto dal client. Se il dominio nel browser o nell’API non coincide con i Subject Alternative Name del certificato, la connessione viene rifiutata.

Controlla che il certificato copra:

• il dominio principale
• eventuali sottodomini
• alias, CDN o endpoint API separati

Un caso frequente è il passaggio da www a dominio nudo, o viceversa, senza aggiornare il certificato.

4. Controlla data e ora del server

Se l’orologio del server è fuori sincronizzazione, un certificato può risultare “non ancora valido” o “già scaduto” anche se in realtà non lo è. Questo problema è comune dopo reboot, su VM sospese o su host con NTP disattivato.

Verifica subito:

• data e ora di sistema
• stato della sincronizzazione NTP
• differenze tra nodo applicativo e bilanciatore

timedatectl status

5. Isola il punto in cui fallisce la negoziazione

Se il certificato sembra corretto, il problema potrebbe essere nel protocollo o nella configurazione del server. Prova a forzare una connessione dettagliata e osserva il handshake.

openssl s_client -connect esempio.it:443 -servername esempio.it -showcerts

Se il comando si interrompe prima di mostrare il certificato, il problema può essere legato a:

• porta sbagliata
• firewall o ACL
• proxy intermedio
• configurazione TLS incompatibile

6. Verifica la configurazione del servizio

Su web server e bilanciatori, il certificato corretto può essere caricato ma non usato. Dopo rinnovi o deploy, controlla che il virtual host punti al file giusto e che il servizio sia stato ricaricato davvero.

Attenzione a questi errori tipici:

• certificato aggiornato, ma servizio non ricaricato
• file nuovo copiato nel path sbagliato
• più vhost che condividono la stessa porta con configurazioni diverse
• redirect che portano a un host non coperto dal certificato

7. Non trascurare i client e i trust store

Talvolta il problema non è sul server, ma sul client. Un trust store obsoleto, una CA mancante o un proxy aziendale che intercetta il traffico possono generare errori apparentemente simili a un guasto TLS.

Se l’errore compare solo su una macchina o solo su una rete, confronta:

• versione del sistema operativo
• bundle CA installato
• presenza di proxy o ispezione SSL

Checklist finale

1. Controlla scadenza del certificato.
2. Verifica la catena completa.
3. Confronta hostname richiesto e SAN.
4. Sincronizza data e ora.
5. Testa l’handshake con openssl s_client.
6. Conferma che il servizio abbia ricaricato la configurazione corretta.

Con questi passaggi puoi distinguere rapidamente un problema di certificato da un errore di configurazione o da un guasto di rete. In ambito sicurezza, la velocità della diagnosi conta: riduce i tempi di fermo e limita il rischio di applicare fix inutili o incompleti.

Se il problema persiste, passa al confronto tra ambiente funzionante e ambiente guasto: spesso basta una differenza minima nel file di configurazione, nel trust store o nel nome esposto dal servizio.