{"id":11576,"date":"2026-09-18T12:23:50","date_gmt":"2026-09-18T12:23:50","guid":{"rendered":"https:\/\/www.visilay.com\/?p=11576"},"modified":"2026-09-18T12:23:50","modified_gmt":"2026-09-18T12:23:50","slug":"ssl","status":"publish","type":"post","link":"https:\/\/www.visilay.com\/it\/blog\/ssl\/","title":{"rendered":"SSL: cos'\u00e8, come funziona e quanto dura oggi un certificato"},"content":{"rendered":"\n

SSL (Secure Sockets Layer) \u00e8 il protocollo che cifra i dati scambiati fra il browser di chi visita un sito e il server che lo ospita, in modo che chiunque intercetti la connessione veda solo caratteri illeggibili al posto di password, email e numeri di carta.<\/p>\n\n\n\n

Il nome per\u00f2 \u00e8 sopravvissuto alla tecnologia. Il protocollo che gira davvero sul tuo sito si chiama TLS, e SSL \u00e8 rimasto come etichetta commerciale sui certificati che si comprano. Se cerchi la cosa che nel 2026 conta in pratica, non \u00e8 quale certificato scegli: \u00e8 ogni quanto lo rinnovi. Da marzo il limite massimo \u00e8 sceso a 200 giorni e continuer\u00e0 a scendere fino a 47.<\/p>\n\n\n\n

Il protocollo si chiama TLS, e delle versioni di SSL non ne resta in piedi nessuna<\/h2>\n\n\n\n

SSL 3.0 \u00e8 stato deprecato dall'IETF con la RFC 7568<\/a> nel giugno 2015, un documento il cui nome di lavorazione era letteralmente draft-ietf-tls-sslv3-diediedie<\/em>. Il successore ha fatto la stessa fine nelle sue prime due versioni: la RFC 8996<\/a>, pubblicata nel 2021, stabilisce che TLS 1.0 e TLS 1.1 MUST NOT be used<\/em> e sposta entrambe le specifiche in stato Historic.<\/p>\n\n\n\n

Restano TLS 1.2, che aveva gi\u00e0 sostituito la 1.1 nel 2008, e TLS 1.3, pubblicata come RFC 8446<\/a> nel 2018. Quando un hosting italiano ti vende un \u00abcertificato SSL\u00bb, quello che installi \u00e8 un certificato X.509 che verr\u00e0 usato da TLS. La sigla vecchia \u00e8 rimasta perch\u00e9 cambiarla avrebbe voluto dire riscrivere pannelli di controllo, listini e documentazione di mezzo settore.<\/p>\n\n\n\n

Cosa contiene un certificato e chi lo firma<\/h2>\n\n\n\n

Un certificato \u00e8 un file che sta sul server e contiene il nome di dominio, la chiave pubblica, la data di emissione, quella di scadenza e la firma di chi lo ha rilasciato. Chi lo rilascia \u00e8 un'autorit\u00e0 di certificazione: DigiCert, Sectigo, GlobalSign, Let's Encrypt. I browser si fidano di un elenco di autorit\u00e0 che portano preinstallato, e un certificato che tu firmi da solo tecnicamente funziona ma non \u00e8 in quell'elenco, quindi Chrome e Firefox lo rifiutano.<\/p>\n\n\n\n

All'apertura della connessione browser e server fanno un handshake: il server manda il certificato, il browser controlla che la firma sia valida e che il dominio corrisponda, poi le due parti si accordano su una chiave di sessione con cui cifrare tutto il resto dello scambio. Dura millesimi di secondo e si ripete a ogni sessione nuova. \u00c8 la parte di SEO tecnica<\/a> che nessuno guarda finch\u00e9 non smette di funzionare.<\/p>\n\n\n\n

DV, OV ed EV cambiano la verifica, non la crittografia<\/h2>\n\n\n\n

Su questo punto la prima pagina italiana di Google \u00e8 imprecisa in pi\u00f9 di un risultato. Diverse pagine scrivono che i certificati DV offrono \u00abuna crittografia minima\u00bb rispetto a OV ed EV. Non funziona cos\u00ec: la forza della cifratura dipende dalla versione di TLS negoziata e dalla cipher suite che client e server scelgono, non dal tipo di certificato. Un DV gratuito di Let's Encrypt e un EV da qualche centinaio di euro producono la stessa identica connessione. Quello che cambia \u00e8 chi ha verificato cosa prima di firmare.<\/p>\n\n\n\n

Tipo<\/th>Cosa verifica l'autorit\u00e0<\/th>Tempi tipici<\/th>Cosa vede l'utente<\/th>Cifratura<\/th><\/tr><\/thead>
DV (Domain Validated)<\/td>Solo il controllo del dominio: un record DNS, un file sul server o una mail all'indirizzo di contatto<\/td>Minuti<\/td>Lucchetto<\/td>Identica<\/td><\/tr>
OV (Organization Validated)<\/td>Dominio pi\u00f9 esistenza legale dell'organizzazione<\/td>Giorni<\/td>Lucchetto; dati azienda nei dettagli del certificato<\/td>Identica<\/td><\/tr>
EV (Extended Validation)<\/td>Dominio pi\u00f9 verifica documentale approfondita dell'organizzazione<\/td>Fino a una settimana<\/td>Lucchetto; dati azienda nei dettagli del certificato<\/td>Identica<\/td><\/tr><\/tbody><\/table>
I tre livelli di validazione differiscono per il controllo di identit\u00e0 svolto dall'autorit\u00e0, non per la protezione della connessione.<\/figcaption><\/figure>\n\n\n\n

La barra verde con il nome dell'azienda, che pi\u00f9 di una pagina italiana descrive ancora come il segno distintivo dell'EV, non esiste pi\u00f9. La documentazione di Chromium<\/a> spiega che a partire da Chrome 77 quell'indicatore \u00e8 stato spostato dentro il pannello Page Info, quello che si apre cliccando sul lucchetto. La ragione: un esperimento sul campo del team Chrome Security UX, insieme a una serie di studi accademici precedenti, aveva mostrato che gli utenti non cambiavano comportamento quando l'indicatore veniva rimosso. Apple aveva gi\u00e0 fatto la stessa scelta in Safari nel 2018, con iOS 12 e macOS 10.14.<\/p>\n\n\n\n

Per un sito aziendale italiano che non gestisce pagamenti in proprio, quindi, la differenza di prezzo fra DV ed EV compra una riga in pi\u00f9 in un pannello che quasi nessuno apre.<\/p>\n\n\n\n

La durata dei certificati sta crollando, ed \u00e8 il cambiamento che ti riguarda<\/h2>\n\n\n\n

L'11 aprile 2025 il CA\/Browser Forum ha approvato il ballot SC-081v3<\/a> con 25 voti favorevoli e nessun contrario fra le autorit\u00e0 di certificazione, e con il voto unanime dei quattro produttori di browser che siedono al tavolo: Apple, Google, Microsoft e Mozilla. Il ballot ha riscritto la sezione 6.3.2 dei Baseline Requirements<\/a>, che fissa quanto pu\u00f2 durare al massimo un certificato TLS pubblico.<\/p>\n\n\n\n

Certificati emessi dal<\/th>Fino al<\/th>Durata massima<\/th><\/tr><\/thead>
(regime precedente)<\/td>15 marzo 2026<\/td>398 giorni<\/td><\/tr>
15 marzo 2026<\/td>15 marzo 2027<\/td>200 giorni<\/td><\/tr>
15 marzo 2027<\/td>15 marzo 2029<\/td>100 giorni<\/td><\/tr>
15 marzo 2029<\/td>in poi<\/td>47 giorni<\/td><\/tr><\/tbody><\/table>
Il calendario di riduzione della validit\u00e0 massima. Fonte: CA\/Browser Forum, TLS Baseline Requirements, sezione 6.3.2<\/a>.<\/figcaption><\/figure>\n\n\n\n

Siamo dentro la prima finestra: un certificato emesso oggi non pu\u00f2 superare i 200 giorni, e i Baseline Requirements raccomandano di restare sotto i 199. Nel 2029 saranno 47, cio\u00e8 poco pi\u00f9 di sei settimane. Lo stesso ballot accorcia anche i tempi di riutilizzo dei dati di validazione del dominio, che scendono progressivamente da 398 a 10 giorni.<\/p>\n\n\n\n

La conseguenza operativa \u00e8 semplice: rinnovare a mano, segnandosi la scadenza sul calendario, smette di funzionare. Con 47 giorni di validit\u00e0 un sito va rinnovato otto volte l'anno. Il protocollo ACME e i client che lo implementano, certbot in testa, esistono da anni proprio per questo, e la maggior parte degli hosting italiani li ha gi\u00e0 integrati nel pannello. Conviene verificare oggi se il rinnovo del tuo sito \u00e8 automatico, perch\u00e9 un certificato scaduto non peggiora il posizionamento: rende il sito irraggiungibile dietro una schermata di errore che il visitatore deve superare a mano, e quasi nessuno lo fa.<\/p>\n\n\n\n

Quanto pesa davvero HTTPS sul posizionamento<\/h2>\n\n\n\n

Google ha annunciato HTTPS come fattore di ranking il 7 agosto 2014, in un post firmato da Zineb Ait Bahajji e Gary Illyes. Vale la pena rileggere come l'hanno scritto, perch\u00e9 la formulazione \u00e8 molto pi\u00f9 prudente di quanto il settore abbia poi raccontato: \u00abper ora \u00e8 solo un segnale molto leggero, che riguarda meno dell'1% delle query globali e pesa meno di altri segnali come i contenuti di qualit\u00e0\u00bb<\/a>.<\/p>\n\n\n\n

Da allora Google non ha pubblicato alcun aggiornamento su quel peso. Il numero pubblico pi\u00f9 recente sull'argomento ha quindi undici anni, e va letto per quello che \u00e8: HTTPS sta molto in basso fra i fattori di ranking<\/a>. Quello che sposta davvero i risultati sta altrove. Chrome segnala come non sicura qualsiasi pagina servita in HTTP, un form di contatto senza cifratura mostra un avviso esplicito accanto al campo, e su una pagina marcata in quel modo un checkout non si chiude. Se hai un e-commerce<\/a>, la questione \u00e8 di conversione prima ancora che di ranking.<\/p>\n\n\n\n

Cosa si rompe quando un sito passa a HTTPS<\/h2>\n\n\n\n

Installare il certificato \u00e8 la parte facile. I problemi arrivano da quello che sta intorno, e sono sempre gli stessi quattro. La documentazione di Google sull'attivazione di HTTPS<\/a> li elenca tutti.<\/p>\n\n\n\n