Let’s Encrypt: dal 2027 i certificati passano da 90 a 64 giorni (e poi a 45 nel 2028)
Il 10 febbraio 2027 Let’s Encrypt cambierà la durata predefinita dei certificati TLS da 90 a 64 giorni. Non è un capriccio: è il passo successivo di u
Altro...
Il 10 febbraio 2027 Let’s Encrypt cambierà la durata predefinita dei certificati TLS da 90 a 64 giorni. Non è un capriccio: è il passo successivo di u
Altro...Il 10 febbraio 2027 Let’s Encrypt cambierà la durata predefinita dei certificati TLS da 90 a 64 giorni. Non è un capriccio: è il passo successivo di una roadmap annunciata da tempo, che punta a portare la validità dei certificati pubblici fino a 45 giorni nel 2028, in linea con i nuovi requisiti del CA/#Browser Forum che vincolano ormai tutte le Certification Authority pubbliche. Per chi gestisce infrastrutture #web, VPN, API gateway o semplicemente un parco server con certificati emessi da Let’s Encrypt, il cambiamento tocca in pieno l’automazione del rinnovo: gli script con intervalli “hardcoded” di 60 o 80 giorni, ancora comuni in molti ambienti, smetteranno di funzionare correttamente.
Il calendario del cambiamentoLet’s Encrypt ha pubblicato un calendario preciso, con un periodo di test prima di ogni passaggio in produzione:
13 maggio 2026 — il profilo ACME tlsserver passa già a certificati da 45 giorni, in modalità opt-in per chi vuole anticipare i tempi.
14 ottobre 2026 — i certificati da 64 giorni iniziano a essere emessi nell’ambiente di staging, per permettere ai gestori di infrastrutture di testare l’impatto prima del rilascio in produzione.
10 febbraio 2027 — il profilo predefinito classic passa a 64 giorni di validità, con un periodo di riutilizzo #dell’autorizzazione (authorization reuse) ridotto da 30 a 10 giorni.
11 maggio 2027 — data prevista in cui l’ultimo certificato da 90 giorni emesso prima del cambio scadrà naturalmente.
16 febbraio 2028 — il profilo classic passa a 45 giorni, con riutilizzo dell’autorizzazione ridotto a sole 7 ore.
2029 — ulteriore riduzione dei periodi massimi di riutilizzo della validazione.
I certificati già emessi mantengono la loro scadenza originale: il cambiamento si applica solo alle nuove emissioni e ai rinnovi effettuati dopo ciascuna data. Rate limit, endpoint ACME e catene di emissione restano invariati.
Perché Let’s Encrypt accorcia la validitàLa motivazione dichiarata è ridurre la finestra di esposizione in caso di compromissione della chiave privata o di mis-issuance, e rendere più efficienti i meccanismi di revoca. Con certificati che vivono poche settimane, un certificato compromesso o emesso per errore ha un impatto temporale molto più limitato rispetto a uno valido novanta giorni — anche quando la revoca esplicita è lenta o non avviene affatto, perché il certificato scade comunque in fretta. È la stessa logica da anni dietro il progressivo accorciamento dei certificati nel settore: dai 3 anni di un tempo, ai 2, a 1, fino ai 90 giorni introdotti da Let’s Encrypt stessa nel 2015 come standard de facto del web pubblico.
Il profilo giusto per ogni esigenzaLet’s Encrypt offre oggi tre profili selezionabili lato client ACME:
classic — il profilo predefinito, oggetto del cambiamento: 90 giorni oggi, 64 da febbraio 2027, 45 dal 2028.
tlsserver — già a 45 giorni dal maggio 2026, pensato per chi vuole adottare in anticipo le validità più brevi.
shortlived — certificati da appena 6 giorni, per scenari ad altissima automazione dove la rotazione continua è parte integrante del modello di sicurezza (ad esempio ambienti #cloud-native con emissione automatizzata a ogni deploy).
Il profilo si imposta nella configurazione del client ACME (certbot, acme.sh, #lego, win-acme e simili supportano o stanno aggiungendo il parametro), non lato #DNS o lato server web.
ARI: lasciate che sia Let’s Encrypt a dirvi quando rinnovareIl meccanismo chiave per affrontare senza stress l’accorciamento della validità è ARI (ACME Renewal Information): un’estensione del protocollo ACME con cui Let’s Encrypt comunica direttamente al client la finestra ottimale di rinnovo per ogni singolo certificato, invece di lasciare che sia lo script a calcolarla con una soglia fissa. I client che implementano ARI (certbot dalla versione 2.9, e la maggior parte dei client moderni) non richiedono alcuna modifica: continueranno a rinnovare al momento giusto anche quando la validità scenderà a 64 e poi a 45 giorni. Vale comunque la pena verificare nella documentazione del proprio client che il supporto ARI sia effettivamente abilitato, non solo disponibile.
Checklist operativa per prepararsiPer chi gestisce certificati Let’s Encrypt in produzione, questi sono i passaggi concreti da affrontare prima di febbraio 2027:
Verificare il supporto ARI del proprio client ACME (certbot, acme.sh, Caddy, Traefik, cert-manager su #Kubernetes, ecc.) e assicurarsi che sia attivo.
Testare in staging a partire dal 14 ottobre 2026, puntando il client all’ambiente di staging di Let’s Encrypt per verificare che il rinnovo a 64 giorni funzioni correttamente nella propria pipeline.
Cercare valori hardcoded in cron job, wrapper script e runbook: soglie fisse come 83, 80 o 60 giorni vanno sostituite con la logica “rinnova a due terzi della validità” (per un certificato da 64 giorni, circa al giorno 43, con un margine di circa 21 giorni) oppure, meglio ancora, delegate ad ARI.
Automatizzare reload e deploy del certificato rinnovato: con rinnovi più frequenti, un passaggio manuale dimenticato diventa un problema molto più probabile.
Aggiungere alerting sui fallimenti di rinnovo, non solo sulla scadenza imminente: con cicli di 64 o 45 giorni, un fallimento silenzioso lascia meno tempo di reazione.
Uno sguardo oltre il 2027: DNS-PERSIST-01Parallelamente alla riduzione delle validità, è in fase di standardizzazione presso CA/Browser Forum e IETF un nuovo metodo di validazione chiamato DNS-PERSIST-01, atteso nel 2026. L’idea è che il record TXT usato per la validazione del dominio non debba essere aggiornato a ogni rinnovo: lo si imposta una sola volta, riducendo la dipendenza dall’automazione DNS e dal riutilizzo dell’autorizzazione che, come visto, si sta progressivamente accorciando. È un tassello pensato proprio per rendere sostenibili rinnovi sempre più frequenti anche per chi #usa la validazione DNS-01 in ambienti con DNS gestito manualmente o con permessi ristretti.
ConclusioneIl passaggio da 90 a 64 giorni non è un’emergenza da gestire in extremis, ma nemmeno un dettaglio da ignorare: chi ha automatizzato correttamente il rinnovo con un client ACME moderno e supporto ARI probabilmente non dovrà toccare nulla. Chi invece ha script scritti anni fa con soglie fisse, o processi di rinnovo semi-manuali, ha una finestra di oltre un anno — da oggi a febbraio 2027 — per testare in staging, ripulire l’automazione e abilitare l’alerting. Vista la direzione dichiarata verso i 45 giorni nel 2028 e oltre, è un lavoro che conviene comunque fare ora: i cicli di vita dei certificati pubblici continueranno ad accorciarsi.
