Il tuo sito ha il lucchetto nel browser, quindi "è già sicuro". È la frase che sentiamo di più e la più ingannevole. Il lucchetto dice solo che esiste un certificato valido per quel dominio: non dice nulla su quali versioni del protocollo accetti, quali cifrari negozi, se la catena è completa o quando scade. Per questo gli strumenti di analisi danno un voto, da A+ a F, e per questo due siti con il lucchetto possono stare agli estremi opposti. Questa guida spiega cosa misura ogni parte di quel voto, quale configurazione è ragionevole nel 2026 e come verificare la tua con due comandi.
Cosa valuta un voto TLS
Gli strumenti seri combinano sette controlli. I primi due sono eliminatori: se falliscono, il voto scende a F senza guardare il resto.
- Certificato valido: emesso da un'autorità riconosciuta, per il dominio corretto, entro il suo periodo di validità.
- Catena completa: il certificato intermedio che collega il tuo all'autorità root viene inviato insieme a esso.
- Versioni del protocollo: quali TLS accetti e quali rifiuti.
- Cifrari: quali algoritmi offri e in che ordine.
- Reindirizzamento: se HTTP porta a HTTPS in tutto il sito.
- HSTS: se dici al browser di non usare mai più HTTP.
- Vulnerabilità note: rinegoziazione insicura, compressione, gli attacchi con nome proprio del decennio scorso.
Versioni: solo 1.2 e 1.3
TLS 1.0 e 1.1 sono obsoleti dal 2020 e i browser li rifiutano. Se il tuo server li accetta ancora, il voto scende perché un attaccante può forzare un client vecchio a usarli. TLS 1.2 è il minimo accettabile; TLS 1.3 è lo standard attuale: meno andata e ritorno nella connessione, cifrari moderni obbligatori e senza le opzioni insicure delle versioni precedenti. La configurazione corretta oggi è accettare 1.2 e 1.3 e nient'altro. Se usi Vercel, Netlify, Cloudflare o un hosting gestito, è già così; se amministri il tuo nginx o un bilanciatore, controllalo.
Cifrari: quello che conta davvero
Il cifrario definisce come si scambia la chiave e come si protegge il traffico. Due cose fanno la differenza. La prima è la segretezza in avanti perfetta (i cifrari che iniziano con ECDHE): se qualcuno ruba la tua chiave privata in futuro, non può decifrare il traffico che ha registrato prima. La seconda è evitare algoritmi rotti o deboli: RC4, 3DES, le vecchie modalità CBC e lo scambio di chiave RSA puro. Una lista ragionevole per TLS 1.2 si riduce a ECDHE con AES-GCM o ChaCha20; in TLS 1.3 il protocollo permette ormai solo cifrari moderni, un motivo in più per attivarlo.
La catena di certificati: il difetto invisibile
Il tuo certificato è firmato da un intermedio, e l'intermedio è firmato da una root che i dispositivi già conoscono. Il server deve inviare il tuo certificato e l'intermedio. Se dimentichi l'intermedio, Chrome su desktop lo scarica per conto suo e non vedrai nessun errore; ma molti telefoni, curl, i bot di IA e le integrazioni di pagamento falliscono con un "certificato non attendibile". È il difetto più comune nei server configurati a mano e il più difficile da notare perché "a me funziona". Verificalo così:
openssl s_client -connect tuodominio.com:443 -servername tuodominio.com </dev/null 2>/dev/null | grep -E "s:|i:|Verify return"Devono comparire almeno due certificati nella catena e la verifica deve finire con Verify return code: 0 (ok).
Dominio e nomi alternativi
Il certificato deve coprire esattamente i nomi che usi: tuodominio.com e www.tuodominio.com sono due nomi diversi. Un certificato solo per la root fa dare errore a www, e viceversa. I certificati attuali elencano più nomi nel campo SAN, e i wildcard (*.tuodominio.com) coprono i sottodomini di un livello. Controlla anche i sottodomini dimenticati: api, app, staging con certificati scaduti sono un classico.
Scadenza: sempre più corta
I certificati di Let's Encrypt durano 90 giorni, il massimo permesso dai browser oggi è 398 e l'industria ha concordato di abbassarlo progressivamente fino a 47 giorni nel 2029. Il messaggio è chiaro: il rinnovo deve essere automatico. Le piattaforme gestite lo fanno da sole; se hai il tuo server, usa un client ACME con rinnovo programmato e, soprattutto, un avviso esterno che ti segnali se mancano meno di 14 giorni. Il down per certificato scaduto è il più stupido e il più frequente.
Reindirizzamento e HSTS
Tutto il traffico HTTP deve reindirizzare a HTTPS con un 301, su tutte le rotte, non solo in home. E una volta che tutto funziona in HTTPS, l'header Strict-Transport-Security dice al browser di non riprovare HTTP per il tempo che indichi, eliminando il piccolo varco della prima richiesta. Con includeSubDomains e preload puoi includere il tuo dominio nella lista che i browser portano di fabbrica. È la differenza abituale tra una A e una A+. Come si configura, in header di sicurezza HTTP.
Contenuto misto
Un dettaglio che non influisce sul voto del certificato ma sì sul lucchetto: se la tua pagina HTTPS carica un'immagine, uno script o un font via HTTP, il browser lo blocca o segna la pagina come non sicura. Di solito viene da URL copiati da un vecchio template. Cercalo nel sorgente con http:// e cambialo in percorsi relativi o HTTPS.
Se sei su una piattaforma gestita
Vercel, Netlify, Cloudflare Pages, Railway o Render emettono e rinnovano il certificato, impongono versioni moderne e scelgono cifrari sicuri. Non devi toccare nulla di tutto questo. Quello che resta tuo: aggiungere HSTS, eliminare il contenuto misto, reindirizzare i domini alternativi e tenere d'occhio i sottodomini che puntano altrove.
Perché conta oltre il voto
Un TLS debole permette di intercettare sessioni su reti pubbliche, e un certificato configurato male fa fallire il tuo sito su dispositivi che non vedi. I processori di pagamento richiedono TLS 1.2 come minimo per rispettare PCI DSS. Google usa HTTPS come segnale di posizionamento e i browser segnano come "non sicuro" tutto ciò che non ce l'ha. E, più prosaicamente, un certificato scaduto un sabato mattina è un sito giù finché qualcuno non se ne accorge.
Verificarlo in trenta secondi
curl -sIL http://tuodominio.com | grep -iE "^(HTTP|location|strict-transport)"
openssl s_client -connect tuodominio.com:443 -servername tuodominio.com -tls1_1 </dev/null 2>&1 | grep -iE "alert|error" | head -1Il primo deve mostrare un 301 verso https:// e poi l'header HSTS. Il secondo prova a connettersi con TLS 1.1 e deve fallire: se si connette, accetti una versione obsoleta.
Scanaris controlla il tuo TLS a ogni scansione
Scanaris verifica versioni del protocollo, cifrari, catena completa, nomi del certificato, giorni alla scadenza, reindirizzamento e HSTS, e ti avvisa via email prima che il certificato scada. Ogni riscontro porta un fix prompt con la configurazione esatta per il tuo server o la tua piattaforma. Sono controlli in sola lettura: si connette al tuo sito come farebbe un browser. Per vedere tutto ciò che controlla in trenta secondi, leggi come sapere se il tuo sito è sicuro in 5 minuti.
Domande frequenti
Che differenza c'è tra SSL e TLS?
SSL è il vecchio nome del protocollo, ritirato anni fa perché insicuro. Quello che si usa oggi è TLS, ma la gente continua a dire "certificato SSL". A fini pratici, quando leggi SSL pensa TLS.
Mi serve un certificato a pagamento?
No. I certificati gratuiti di Let's Encrypt o quelli emessi dalla tua piattaforma cifrano esattamente allo stesso modo. Quelli a pagamento aggiungono validazione dell'organizzazione o garanzie, non più sicurezza nella connessione.
Perché prendo una B se il mio certificato è valido?
Di solito perché accetti TLS 1.0 o 1.1, offri cifrari deboli o non invii l'header HSTS. Il certificato è solo una delle sette cose che si guardano.