# Let's Encrypt: certificati validi 6 giorni e per indirizzi IP
Table of Contents
Chi gestisce un sito conosce i certificati TLS: il piccolo documento digitale che dimostra l’identità di un server e permette al browser di cifrare la connessione, quello che accende il lucchetto accanto all’indirizzo. Fino a poco tempo fa un certificato di Let’s Encrypt durava 90 giorni. Dal 15 gennaio 2026 l’autorità mette a disposizione di tutti due novità: certificati che scadono dopo poco più di sei giorni, e certificati che coprono un indirizzo IP invece di un nome a dominio. Per chi naviga non cambia nulla. Per chi amministra server è un segnale chiaro sulla direzione presa dal web: la vita dei certificati si accorcia, proprio mentre cresce la quota di traffico già protetta da crittografia post-quantum, e l’automazione diventa l’unico modo sensato di gestirli.
La notizia in breve
Let’s Encrypt è un’Autorità di Certificazione (in inglese Certificate Authority, o CA): l’ente che emette i certificati, cioè che garantisce l’identità di un sito. È gratuita e da anni è la più usata al mondo, perché ha reso l’emissione dei certificati un’operazione automatica invece di un acquisto manuale.
Le due funzioni annunciate erano in prova da mesi con accesso limitato. Dal 15 gennaio 2026 sono passate a disponibilità generale, cioè sono aperte a chiunque:
- Certificati a vita breve, validi 160 ore, poco più di sei giorni.
- Certificati per indirizzi IP, sia IPv4 sia IPv6.
Restano due opzioni facoltative. Il certificato standard di Let’s Encrypt continua a durare 90 giorni: chi non fa nulla non nota alcuna differenza. Chi vuole i certificati brevi o quelli per IP deve richiederli in modo esplicito.
Sei giorni invece di novanta
Per ottenere un certificato a vita breve non basta chiederlo e basta: il programma che dialoga con l’autorità deve saper indicare un profilo, una sorta di modello di certificato. Il profilo si chiama shortlived. È identico a quello usato normalmente per i siti web, con un’unica differenza: il certificato dura circa sei giorni invece di tre mesi.
Quella durata così corta non è casuale. Esiste una regola di settore, le Baseline Requirements, che definisce una categoria a parte, i certificati a vita breve. Un certificato che rientra in questa categoria ha un privilegio: non deve contenere alcuna informazione sulla revoca. Per capire perché è un vantaggio serve fare un passo indietro e spiegare cos’è la revoca.
Perché così brevi: il problema della revoca
Ogni certificato è legato a una chiave privata, un file segreto che deve restare sul server e non uscire mai. Se quella chiave viene rubata - per un attacco, una configurazione sbagliata, un backup finito nel posto sbagliato - chi la possiede può fingersi il sito legittimo fino a quando il certificato resta valido. Questo intervallo si chiama finestra di compromissione: più lungo è il certificato, più a lungo un furto può fare danni senza che nessuno se ne accorga.
In teoria esiste un rimedio: la revoca, cioè dichiarare un certificato non più valido prima della sua scadenza naturale. Nella pratica la revoca funziona male. I browser non sempre controllano se un certificato è stato revocato, e i meccanismi pensati per avvisarli sono lenti o poco affidabili. Il risultato è che, anche dopo una revoca, molti visitatori continuano a fidarsi di un certificato che non dovrebbero più accettare.
I certificati a vita breve aggirano il problema alla radice. Se un certificato dura sei giorni, la finestra di compromissione è di sei giorni al massimo: dopo, scade da solo. Non serve revocarlo, perché sparisce comunque in fretta. È un modo meno elegante ma più solido di ottenere lo stesso risultato. È anche la ragione per cui Let’s Encrypt ha detto di voler portare la durata standard dagli attuali 90 giorni a 45 nei prossimi anni, lo stesso percorso di riduzione fissato a livello di settore con il traguardo dei 47 giorni approvato dal CA/Browser Forum: la direzione è ridurre il tempo in cui un errore può fare danni.
La fine di OCSP
Questa scelta si lega a un cambiamento avvenuto pochi mesi prima. Per anni il modo principale di controllare se un certificato era stato revocato si chiamava OCSP (Online Certificate Status Protocol): a ogni visita, il software poteva chiedere in tempo reale all’autorità “questo certificato è ancora valido?”.
Il 6 agosto 2025 Let’s Encrypt ha spento il suo servizio OCSP. Le ragioni sono due. La prima è la privacy: ogni interrogazione OCSP rivelava all’autorità quale sito una persona stava visitando, e da quale indirizzo. La seconda è la scala: al suo apice il servizio gestiva circa 340 miliardi di richieste al mese, un’infrastruttura enorme da mantenere. Al posto di OCSP resta un solo meccanismo, le CRL (Certificate Revocation List), cioè elenchi di certificati revocati pubblicati periodicamente.
In un mondo in cui il controllo in tempo reale non esiste più, i certificati a vita breve hanno ancora più senso: non hanno bisogno di essere revocati, quindi non dipendono da un sistema di revoca che ormai è volutamente più leggero.
Certificati per un indirizzo IP
La seconda novità risolve un problema diverso. Di solito un certificato copre un nome a dominio, per esempio esempio.it. Ma non tutto ha un dominio: ci sono servizi raggiungibili solo tramite il loro indirizzo numerico, come 203.0.113.10 o un indirizzo IPv6. Fino a ieri, per quei casi, un certificato pubblicamente riconosciuto non era ottenibile e restava solo la strada dei certificati “fatti in casa”, che i browser segnalano come non attendibili.
Ora Let’s Encrypt può emettere certificati che coprono direttamente un indirizzo IP, sia IPv4 sia IPv6. Serve a proteggere connessioni verso servizi che non hanno un nome a dominio: endpoint di infrastruttura, apparati di rete, ambienti tecnici in cui l’indirizzo numerico è tutto ciò che c’è.
Ci sono due vincoli, entrambi legati alla natura degli indirizzi IP. Il primo: un certificato per un indirizzo IP deve essere a vita breve, quindi passa per il profilo shortlived. Il motivo è che un indirizzo IP cambia proprietario molto più spesso di un dominio, e verificarlo di continuo è importante per evitare che finisca a chi non dovrebbe. Il secondo: per dimostrare di controllare l’indirizzo si possono usare solo due metodi di verifica, quello basato su una risposta HTTP e quello basato sulla connessione TLS. Il metodo via DNS, comodo per i domini, qui non è utilizzabile, perché un indirizzo IP non ha voci DNS da modificare.
Cosa serve per usarli
Il requisito pratico è uno solo: il programma che gestisce i certificati - il client ACME, dove ACME è il protocollo standard con cui un server ottiene e rinnova i certificati da solo - deve saper richiedere un profilo. È una funzione recente, quindi conviene usare una versione aggiornata del proprio client. I client più diffusi, tra cui certbot, hanno già istruzioni dedicate per selezionare il profilo shortlived.
Il resto è automazione, ed è la parte importante. Un certificato che dura sei giorni va rinnovato ogni pochi giorni: a mano è impensabile. Ma per un sistema automatico rinnovare ogni giorno o ogni tre giorni non è più faticoso che rinnovare ogni due mesi. Chi già affida i rinnovi a un client ACME che gira da solo non deve cambiare quasi nulla; chi rinnova ancora a mano, con questi certificati, semplicemente non può farlo.
In sintesi
Let’s Encrypt ha aperto a tutti due opzioni facoltative: certificati validi poco più di sei giorni e certificati per indirizzi IP. I primi accorciano al minimo il tempo in cui un certificato compromesso può fare danni, in un mondo in cui la revoca - e il vecchio servizio OCSP, ormai spento - non offrivano garanzie affidabili. I secondi portano i certificati pubblici anche dove non c’è un dominio. Il filo comune è sempre lo stesso: certificati più brevi, controlli più frequenti, e un’automazione solida come unica condizione per starci dietro, mentre nello stesso periodo anche lo scambio di chiavi post-quantum abilitato di default in Chrome sposta più in generale l’asticella della sicurezza in TLS.
