Spcnet.it Notizie geek e OSS/Linux. Su Telegram: InfoSec ITA Notizie
Home > Articolo > Let’s Encrypt: dal 2027 i certificati passano da 90 a 64 giorni (e poi a 45 nel 2028)
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 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 cambiamento

Let’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 esigenza

Let’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 rinnovare

Il 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 prepararsi

Per chi gestisce certificati Let’s Encrypt in produzione, questi sono i passaggi concreti da affrontare prima di febbraio 2027:

  1. Verificare il supporto ARI del proprio client ACME (certbot, acme.sh, Caddy, Traefik, cert-manager su Kubernetes, ecc.) e assicurarsi che sia attivo.
  2. 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.
  3. 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.
  4. Automatizzare reload e deploy del certificato rinnovato: con rinnovi più frequenti, un passaggio manuale dimenticato diventa un problema molto più probabile.
  5. 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-01

Parallelamente 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.

Conclusione

Il 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.

Fonte: Let’s Encrypt – 64-day certs e ISRG – From 90 to 45.

Condividi: Twitter  |  Facebook  |  LinkedIn
Unisciti alla discussione

Questo è un blog del Fediverso: puoi trovare questo articolo ovunque con @blog@insicurezzadigitale.com e ogni commento/risposta apparirà qui sotto.

Se vuoi commentare su Let’s Encrypt: dal 2027 i certificati passano da 90 a 64 giorni (e poi a 45 nel 2028), utilizza la discussione sul Forum.

>> forum community