Certificati Let's Encrypt a 45 giorni: come riconfigurare il rinnovo prima che scadano

Chi gestisce certificati Let's Encrypt con uno script scritto anni fa e mai più toccato ha una data da segnare: il 13 maggio 2026. Da quel giorno il profilo ACME tlsserver, finora sperimentale, emette certificati validi 45 giorni invece di 90. È il primo gradino di un percorso che, secondo il blog ufficiale di Let's Encrypt, porterà la durata standard dei certificati da 90 a 45 giorni entro il 2028, in linea con i requisiti del CA/Browser Forum.

Il profilo tlsserver resta opt-in: va scelto esplicitamente in configurazione, non è il default. Chi non tocca nulla continua a ricevere certificati a 90 giorni fino al prossimo gradino: il 10 febbraio 2027 Let's Encrypt passerà il profilo classic di default a certificati di 64 giorni con un periodo di riutilizzo dell'autorizzazione di 10 giorni, cosa che riguarderà tutti gli utenti che non hanno scelto i profili tlsserver o shortlived (6 giorni). Il traguardo finale è fissato per il 16 febbraio 2028, quando il profilo classic passerà a certificati di 45 giorni con un periodo di riutilizzo dell'autorizzazione di 7 ore.

Perché uno script "che ha sempre funzionato" può rompersi

Il punto critico non è la data di scadenza in sé, ma gli intervalli di rinnovo scritti a mano. Lo stesso post ufficiale lo dice senza giri di parole: rinnovare a un intervallo fisso di 60 giorni non sarà più sufficiente, mentre un comportamento accettabile è rinnovare approssimativamente a due terzi della vita del certificato corrente.

Tradotto in numeri: con certificati a 90 giorni un cron che gira ogni 60 giorni lascia comunque 30 giorni di margine. Con certificati a 45 giorni, lo stesso cron a 60 giorni prova a rinnovare un certificato già scaduto da due settimane. La regola dei "due terzi" applicata a 45 giorni dà un rinnovo intorno al giorno 30; applicata a 64 giorni (il gradino del 2027) dà un rinnovo intorno al giorno 42-43.

Cosa fa davvero certbot, e cosa cambia

Certbot non rinnova "ogni tot giorni" per calendario: il comando certbot renew controlla la scadenza di ogni certificato presente in /etc/letsencrypt/live/ e rinnova solo quelli che stanno per scadere, secondo la propria logica interna. Il pacchetto standard installa già un cron job o un timer systemd che lancia certbot renew due volte al giorno: chi ha installato certbot da pacchetto di sistema (apt, dnf, snap) non deve toccare nulla di suo, perché il controllo di scadenza è demandato al client stesso, non a un intervallo fisso impostato dall'utente. Il rischio reale è per chi anni fa ha sostituito il timer di sistema con un proprio cron tipo 0 3 1 */2 * certbot renew (un tentativo ogni due mesi): con certificati a 45 giorni, un intervallo di controllo così largo lascia margini troppo stretti o nulli in caso di errore temporaneo (DNS non propagato, rate limit, blocco del provider).

ARI: il meccanismo che Let's Encrypt vuole diventi lo standard

Per evitare di affidarsi a formule empiriche, Let's Encrypt spinge sull'adozione di ARI (ACME Renewal Information), un meccanismo con cui il server comunica al client quando dovrebbe rinnovare, invece di lasciare che sia il client a indovinarlo con una percentuale fissa della validità. Il post ufficiale lo mette al primo posto tra le azioni consigliate: per assicurarsi che il proprio client ACME rinnovi in tempo, Let's Encrypt raccomanda di usare ACME Renewal Information (ARI), mentre chi ha un client che non supporta ancora ARI deve assicurarsi che giri su un programma compatibile con certificati a 45 giorni.

Per chi usa acme.sh o lego, la verifica pratica è semplice: controllare nella changelog del proprio client se è presente il supporto ARI (nelle versioni recenti di entrambi i progetti è stato aggiunto) e, se manca, accorciare manualmente l'intervallo del cron esistente piuttosto che fidarsi del valore di default lasciato all'installazione iniziale.

Il monitoraggio conta più del cron

Un'indicazione che la fonte ufficiale ripete esplicitamente riguarda il controllo a valle: rinnovare manualmente i certificati non è raccomandato, perché con durate più brevi va fatto più spesso, e Let's Encrypt consiglia di avere un sistema di monitoraggio sufficiente ad allertare se un certificato non viene rinnovato quando previsto. In pratica: un controllo esterno che verifica la data di scadenza del certificato esposto (non quella attesa dallo script) via openssl s_client -connect dominio:443 -servername dominio | openssl x509 -noout -enddate, schedulato indipendentemente dal cron di rinnovo, resta la rete di sicurezza più semplice da aggiungere subito, prima ancora di toccare gli script di automazione.

Checklist minima per chi gestisce più domini

• Verificare quale profilo ACME usa la propria configurazione attuale (classic è il default, nessuna azione richiesta prima di febbraio 2027).
• Se si è passati volontariamente a tlsserver per test, verificare che il cron o il timer non assuma più una validità di 90 giorni.
• Separare il controllo di scadenza "reale" (interrogando il certificato esposto) dal log del client ACME: sono due fonti diverse, e la seconda può mentire se il rinnovo fallisce silenziosamente.
• Pianificare, entro inizio 2027, la verifica di tutti i cron personalizzati che sostituiscono il timer di default dei client, perché è lì che si annida la maggior parte dei problemi quando la finestra si restringe.

Fonte: blog ufficiale Let's Encrypt, "Decreasing Certificate Lifetimes to 45 Days", 2 dicembre 2025, https://letsencrypt.org/2025/12/02/from-90-to-45