Ingegneria
Certificati SSL: scadenze, catene e problemi di traffico
Perché i certificati SSL falliscono, perché un sito funziona su PC e non su smartphone e perché pagare per un certificato è quasi sempre inutile.
Un certificato SSL scaduto non rallenta semplicemente un sito web. Lo rende del tutto inaccessibile dietro un avviso di sicurezza a schermo intero del browser che la maggior parte dei visitatori non oltrepasserà mai, e che i crawler dei motori di ricerca considerano un errore bloccante.
Le conversioni si azzerano istantaneamente. E questo accade regolarmente anche ad aziende strutturate, perché il problema si manifesta in modo silenzioso fino al blocco totale.
Ecco le cause reali di errore e come prevenirle.
Scadenza: l'automazione che smette di funzionare in silenzio
I certificati Let's Encrypt hanno una validità di 90 giorni e sono progettati per rinnovarsi automaticamente al 60° giorno. L'automazione elimina il rischio umano — finché il cron job di rinnovo fallisce senza che nessuno se ne accorga per un mese intero.
I rinnovi si interrompono per motivi banali: una regola del firewall che blocca la richiesta di convalida HTTP, lo spostamento della webroot durante un rilascio, la scadenza del token API del DNS, lo spazio su disco esaurito o l'aggiornamento del pacchetto certbot. Nessuna di queste anomalie genera allarmi evidenti. Il certificato smette semplicemente di rinnovarsi e trenta giorni dopo il sito è offline.
La regola fondamentale di protezione: monitorate la data di scadenza effettiva del certificato indipendentemente dal processo di rinnovo. Se l'alert verifica solo "se certbot è stato eseguito", vi state fidando proprio del processo che potrebbe fallire. Se l'alert verifica se il certificato pubblico scade entro 14 giorni, intercettate qualsiasi scenario di errore.
Impostate l'avviso a 14 giorni: avrete due intere settimane per intervenire con calma.
Copertura dei nomi host: il problema del www
Un certificato copre solo i nomi di dominio specificati nel campo Subject Alternative Name (SAN). Un certificato emesso per example.com non copre automaticamente www.example.com a meno che www non sia esplicitamente elencato.
Questo errore spesso non viene notato internamente perché si digita il dominio sempre nello stesso modo. Nel frattempo, una quota di visitatori — chi digita il www o proviene da vecchi collegamenti — si scontra con una schermata di errore di sicurezza.
Verificate sempre entrambe le versioni.
I certificati wildcard coprono un solo livello di sottodominio. *.example.com copre shop.example.com ma non eu.shop.example.com. Inoltre non copre il dominio radice example.com da solo, che deve essere incluso separatamente.
Problemi di catena (Chain): funzionante su desktop, rotto su mobile
Il vostro certificato è firmato da un certificato intermedio, a sua volta firmato da una Certificate Authority radice (Root CA) già considerata attendibile dai browser. Il vostro server ha l'obbligo di trasmettere il certificato intermedio.
Se il server invia unicamente il certificato foglia (leaf), la maggior parte dei browser desktop colma la lacuna scaricando autonomamente l'intermedio mancante. Molti browser per smartphone, client API, dispositivi Android datati e strumenti da riga di comando non lo fanno, bloccando la navigazione per certificato non attendibile.
Ecco perché un sito può sembrare perfetto sul computer dell'ufficio e non funzionare sullo smartphone di un cliente. Non fidatevi del semplice lucchetto sul vostro browser: verificate sempre l'invio della catena completa dei certificati.
Il nostro free SSL checker verifica la completezza della catena oltre alla scadenza e ai nomi host coperti.
Versioni del protocollo TLS
- TLS 1.3 — standard moderno. Completa l'handshake crittografico in un solo round-trip anziché due, offrendo un incremento prestazionale misurabile a ogni connessione.
- TLS 1.2 — requisito minimo accettabile.
- TLS 1.1 e 1.0 — obsoleti, rifiutati dai browser moderni e non conformi agli standard di sicurezza PCI-DSS.
Se il vostro hosting supporta ancora TLS 1.0 o 1.1, è necessario richiedere un aggiornamento della configurazione.
Certificati gratuiti versus a pagamento
Dal punto di vista della sicurezza crittografica, sono identici. Let's Encrypt utilizza gli stessi algoritmi, le stesse chiavi di cifratura e riceve lo stesso trattamento dai browser di un certificato a pagamento da centinaia di euro all'anno.
I certificati a pagamento commerciali offrivano la validazione aziendale (EV) per mostrare la ragione sociale nella barra degli indirizzi.
I browser hanno rimosso la barra verde aziendale da anni. Chrome, Firefox e Safari non mostrano più alcuna differenza visiva. Gli utenti non distinguono un certificato EV da uno gratuito Let's Encrypt.
La scelta trasparente: utilizzate certificati gratuiti a meno che una specifica clausola contrattuale o una certificazione formale non imponga una tipologia differente.
La durata dei certificati si sta riducendo
I browser rifiutano certificati emessi con validità superiore a 398 giorni, e l'industria si sta muovendo verso limiti ancora più stringenti (proposte a 90 e 47 giorni massimi).
La conseguenza pratica è che la gestione manuale dei certificati è al capolinea. Qualsiasi procedura che richieda l'intervento umano per scaricare e caricare file a mano diventerà insostenibile. Automatizzare il processo ora è infinitamente più economico che farlo in emergenza durante un disservizio.
Contenuti misti (Mixed Content)
Un certificato valido non basta se una pagina HTTPS richiama risorse (immagini, script, fogli di stile, font) tramite protocollo non protetto http://.
Script e fogli di stile insicuri vengono bloccati all'istante dai browser, rompendo la grafica o la funzionalità della pagina. Le immagini vengono talvolta caricate ma fanno sparire l'icona del lucchetto di sicurezza.
Le cause tipiche post-migrazione sono percorsi assoluti http:// rimasti salvati nel database o nei contenuti del blog.
Controlli periodici consigliati
Mensilmente, in modo automatizzato:
- Giorni mancanti alla scadenza per il dominio principale e per il terzo livello
www - Integrità della catena di certificazione intermedia
- Versione del protocollo TLS negoziata
Dopo ogni migrazione di hosting o CDN:
- Tutti i controlli precedenti, oltre alla scansione dei contenuti misti sulle pagine principali
Una sola volta:
- Configurate un record DNS di tipo CAA indicando le sole autorità di certificazione autorizzate a emettere certificati per il vostro dominio.
Quest'ultimo passaggio è approfondito nella nostra DNS records guide e verificabile con il nostro DNS lookup tool.