Certificati a 45 giorni: come impostare rinnovo automatico e allarmi prima che scadano

Ad oggi, 15 ottobre 2026, i certificati emessi da Let's Encrypt valgono ancora 90 giorni. Ma il countdown verso i 45 giorni è già scritto nel calendario ufficiale, e chi gestisce server deve tarare rinnovo automatico e allarmi su quella scadenza, non su quella attuale. Questa guida copre certbot su Ubuntu 24.04 LTS con Nginx: timer di sistema, verifica, e un controllo di scadenza che non dipende dal client ACME.

Il calendario che conta

Secondo il blog ufficiale di Let's Encrypt, Let's Encrypt sta riducendo la validità dei certificati: attualmente 90 giorni, che verranno dimezzati a 45 giorni entro il 2028.

Data	Cambiamento	Riuso autorizzazione
13 maggio 2026	Profilo tlsserver opt-in a 45 giorni (early adopter)	invariato, 30 giorni
10 febbraio 2027	Profilo classic di default a 64 giorni	10 giorni
16 febbraio 2028	Profilo classic di default a 45 giorni	7 ore

Le date sono confermate dal post ufficiale: il 13 maggio 2026 Let's Encrypt passerà il profilo ACME tlsserver a certificati di 45 giorni, profilo opt-in per chi vuole testare l'automazione in anticipo; il 16 febbraio 2028 il profilo classic emetterà certificati di 45 giorni con un periodo di riuso dell'autorizzazione di 7 ore. Chi usa oggi il profilo shortlived lavora già con certificati di 6 giorni: il cambio al 64 giorni riguarderà tutti gli utenti che non hanno scelto i profili tlsserver o shortlived (6 giorni).

Il motivo pratico: nei prossimi due anni il passaggio da 90 a 64 e poi a 45 giorni raddoppierà il numero di richieste di rinnovo al giorno; oggi ci si aspetta il rinnovo intorno al giorno 60 di un certificato a 90 giorni, in futuro intorno al giorno 30 di uno a 45 giorni. Con un client ACME che supporta ARI questo avviene automaticamente.

Rinnovo automatico con certbot su Ubuntu 24.04 + Nginx

Il pacchetto certbot installato da repository o snap crea da solo il meccanismo di rinnovo. Verificalo così:

systemctl list-timers --all | grep certbot
systemctl status certbot.timer

Su RHEL e derivate, ma lo schema vale anche per Ubuntu, il timer di sistema parte due volte al giorno e ad ogni esecuzione certbot controlla tutti i certificati gestiti e rinnova quelli entro 30 giorni dalla scadenza.

Prima di fidarti dell'automazione, testa senza toccare i certificati in produzione:

sudo certbot renew --dry-run

Il comando simula l'intero processo di rinnovo, inclusi gli hook configurati, e si collega all'ambiente di staging di Let's Encrypt, non a quello di produzione, quindi non consuma i rate limit reali.

Se vuoi un timer dedicato invece di quello di pacchetto, aggiungi un RandomizedDelaySec nella sezione [Timer]: la randomizzazione distribuisce il carico sull'infrastruttura di Let's Encrypt, pratica corretta e consigliata. Per ricaricare Nginx dopo ogni rinnovo, metti uno script in /etc/letsencrypt/renewal-hooks/deploy/ che esegue systemctl reload nginx.

Un controllo di scadenza indipendente dal client ACME

Il timer di certbot può fallire silenziosamente (porta 80 chiusa, rate limit, hook rotto). Serve una seconda rete, che legge la scadenza vera dal certificato, non dalla configurazione del client:

#!/bin/bash
CERT=/etc/letsencrypt/live/example.com/cert.pem
SOGLIA_WARN=20
SOGLIA_CRIT=7

SCADENZA=$(openssl x509 -enddate -noout -in "$CERT" | cut -d= -f2)
SCADENZA_EPOCH=$(date -d "$SCADENZA" +%s)
OGGI_EPOCH=$(date +%s)
GIORNI_RESTANTI=$(( (SCADENZA_EPOCH - OGGI_EPOCH) / 86400 ))

if [ "$GIORNI_RESTANTI" -le "$SOGLIA_CRIT" ]; then
 LIVELLO="CRITICO"
elif [ "$GIORNI_RESTANTI" -le "$SOGLIA_WARN" ]; then
 LIVELLO="AVVISO"
else
 exit 0
fi

MSG="Certificato $CERT: $GIORNI_RESTANTI giorni residui ($LIVELLO)"
echo "$MSG" | mail -s "[$LIVELLO] Scadenza certificato" ops@example.com
curl -s -X POST -H 'Content-Type: application/json' \
 -d "{\"text\":\"$MSG\"}" https://hooks.example.com/webhook

Mettilo in cron una volta al giorno, separato dal timer di certbot:

0 7 * * * /usr/local/bin/check-cert-expiry.sh

Come tarare le soglie per ogni ciclo di vita

Il criterio ufficiale di Let's Encrypt per chi non usa ARI: se il client non supporta ancora ARI, bisogna assicurarsi che funzioni su una schedulazione compatibile con certificati a 45 giorni; rinnovare a un intervallo fisso di 60 giorni non sarà più sufficiente, mentre rinnovare a circa due terzi della vita del certificato va bene.

Applicando il criterio dei due terzi:

Profilo	Vita certificato	Rinnovo atteso (2/3 vita)	Soglia AVVISO	Soglia CRITICO
classic (oggi)	90 giorni	giorno 60 (30 gg residui)	20 giorni residui	7 giorni residui
classic (dal 10/02/2027)	64 giorni	giorno 43 (21 gg residui)	14 giorni residui	5 giorni residui
tlsserver / classic (dal 16/02/2028)	45 giorni	giorno 30 (15 gg residui)	10 giorni residui	3 giorni residui
shortlived	6 giorni	giorno 4 (2 gg residui)	2 giorni residui	12 ore

Con il profilo shortlived il controllo va in cron ogni ora, non ogni giorno: un margine di 2 giorni residui si consuma in fretta se il rinnovo automatico si inceppa.

ARI e il prossimo passo: DNS-PERSIST-01

Chi usa un client con supporto ARI (ACME Renewal Information) non deve ricalcolare le soglie a mano: è il server di Let's Encrypt a comunicare al client quando rinnovare. Per chi automatizza via DNS-01, in arrivo un nuovo tipo di validazione, DNS-PERSIST-01, che riduce la dipendenza dal riuso dell'autorizzazione perché il record DNS può restare invariato senza ulteriore intervento del client ACME; Let's Encrypt la prevede nel corso del 2026.

Il testo completo del piano è sul blog ufficiale, letsencrypt.org/2025/12/02/from-90-to-45; i comandi certbot sono documentati su eff-certbot.readthedocs.io/en/stable/using.html.