Come Automatizzo il Rinnovo dei Certificati SSL/TLS con Certbot, ACME.sh e Let’s Encrypt: La Mia Guida Pratica

Hosting
ACME.sh, Certbot, Let's Encrypt, Linux, Sicurezza Server, SSL/TLS

Se gestisci server come faccio io da anni, sai benissimo che un certificato SSL/TLS scaduto è uno degli incubi peggiori: il sito va in errore, gli utenti vedono l’avviso “La connessione non è sicura”, le conversioni crollano e Google ti penalizza nel ranking. Ho vissuto questa situazione una volta sola — e mi è bastata per automatizzare tutto in modo che non succedesse mai più.

Nel 2026 il tema dell’automazione dei certificati SSL è più attuale che mai: Let’s Encrypt ha annunciato la riduzione progressiva della validità dei certificati da 90 a 45 giorni, ha introdotto certificati short-lived da 6 giorni, e sta deprecando il supporto a TLS Client Authentication. Se non hai un sistema di rinnovo automatico affidabile, ti aspettano notti insonni. In questa guida vi mostro come ho configurato l’intera pipeline di automazione SSL sui miei server Linux usando Certbot, acme.sh e Let’s Encrypt, con tutti i comandi testati e funzionanti.

Se ti occupi anche di sicurezza WordPress, ti consiglio di leggere il mio articolo su come proteggo WordPress dalle vulnerabilità plugin con virtual patching e WAF, perché un certificato SSL valido è solo il primo livello di difesa.

Cosa Cambia nel 2026: Le Novità Let’s Encrypt che Devi Conoscere

Prima di entrare nella parte pratica, è fondamentale capire cosa sta succedendo nel mondo dei certificati SSL/TLS nel 2026, perché queste novità impattano direttamente sulla tua strategia di automazione.

Riduzione della Validità dei Certificati: Da 90 a 45 Giorni

Let’s Encrypt, in conformità con le nuove regole del CA/Browser Forum Baseline Requirements, sta riducendo gradualmente la validità dei certificati. Ecco la timeline che ho annotato:

Maggio 2026: il profilo ACME tlsserver passa a certificati da 45 giorni (opt-in per early adopter)
Febbraio 2027: il profilo classic di default scende a 64 giorni con un periodo di riuso autorizzazione di 10 giorni
Febbraio 2028: tutti i certificati di default saranno da 45 giorni con riuso autorizzazione di sole 7 ore

Il messaggio è chiaro: se rinnovi manualmente i certificati, questa pratica diventa insostenibile. L’automazione non è più un’opzione, è una necessità.

Certificati Short-Lived da 6 Giorni

Da gennaio 2026, Let’s Encrypt offre in general availability certificati short-lived validi solo 160 ore (circa 6 giorni). Per richiederli basta selezionare il profilo shortlived nel client ACME. Questi certificati non includono URL OCSP o CRL, perché scadono così rapidamente da rendere superflua la revoca tradizionale. Sono perfetti per chi ha un’automazione solida e vuole la massima sicurezza.

Fine del Supporto TLS Client Authentication

Da febbraio 2026, Let’s Encrypt ha rimosso l’Extended Key Usage “TLS Client Authentication” dal profilo di default. Se usi certificati Let’s Encrypt per mutual TLS (mTLS), devi pianificare la migrazione entro maggio 2026, quando anche il profilo temporaneo tlsclient verrà eliminato.

Metodo 1: Automazione con Certbot (Il Classico Affidabile)

Certbot è il client ACME ufficiale della EFF ed è lo strumento che ho usato per primo sui miei server. La versione attuale è la 5.3.1 (febbraio 2026) e supporta i nuovi profili ACME, certificati IP e il flag --preferred-profile.

Installazione di Certbot via Snap

Il metodo consigliato per installare Certbot su qualsiasi distribuzione Linux moderna è tramite Snap, che garantisce aggiornamenti automatici:

# Rimuovi eventuali versioni vecchie installate via apt
sudo apt remove certbot -y

# Installa Certbot via Snap
sudo snap install certbot --classic

# Crea il link simbolico
sudo ln -s /snap/bin/certbot /usr/bin/certbot

# Verifica la versione installata
certbot --version

Emissione del Primo Certificato con Certbot

Nella mia esperienza, il modo più diretto per ottenere un certificato su un server con Nginx è usare il plugin integrato:

# Emetti e configura automaticamente SSL su Nginx
sudo certbot --nginx -d esempio.it -d www.esempio.it

# Oppure, se usi Apache:
sudo certbot --apache -d esempio.it -d www.esempio.it

# Solo emissione (certonly), senza modificare la config web server:
sudo certbot certonly --webroot -w /var/www/esempio.it -d esempio.it -d www.esempio.it

Rinnovo Automatico con Certbot

Certbot installato via Snap crea automaticamente un systemd timer (o un cronjob) che tenta il rinnovo due volte al giorno. Puoi verificare che sia attivo:

# Verifica il timer di rinnovo automatico
sudo systemctl status snap.certbot.renew.timer

# Test di rinnovo senza effettivamente rinnovare
sudo certbot renew --dry-run

All’inizio non funzionava perché il timer non era abilitato sulla mia distribuzione. Ho dovuto forzare l’attivazione:

sudo systemctl enable --now snap.certbot.renew.timer

Certbot e Profili ACME 2026

Con la versione 5.x puoi sfruttare i nuovi profili ACME di Let’s Encrypt. Se vuoi testare i certificati da 45 giorni o i short-lived da 6 giorni:

# Certificato short-lived da 6 giorni
sudo certbot certonly --nginx -d esempio.it --preferred-profile shortlived

# Certificato con profilo tlsserver (presto a 45 giorni)
sudo certbot certonly --nginx -d esempio.it --preferred-profile tlsserver

# Certificato per IP address (richiede profilo shortlived)
sudo certbot certonly --standalone --ip-address 203.0.113.10 --preferred-profile shortlived

Metodo 2: Automazione con ACME.sh (Leggero e Potente)

acme.sh è il mio strumento preferito quando lavoro su server minimali o quando ho bisogno di automazione DNS per wildcard certificates. È uno script shell puro, senza dipendenze, e supporta oltre 150 provider DNS via API.

Installazione di acme.sh

# Installa acme.sh nella home directory
curl https://get.acme.sh | sh -s email=tuaemail@esempio.it

# Ricarica il terminale per attivare l'alias
source ~/.bashrc

# Verifica l'installazione
acme.sh --version

L’installazione crea automaticamente un cron job giornaliero che controlla e rinnova i certificati quando necessario.

Emissione Certificato con Validazione HTTP (Webroot)

# Certificato singolo con webroot
acme.sh --issue -d esempio.it -d www.esempio.it -w /var/www/esempio.it

# Con standalone mode (quando non hai un web server in ascolto)
acme.sh --issue -d esempio.it --standalone

Wildcard Certificate con DNS API (Cloudflare)

Questa è la configurazione che uso per i domini gestiti tramite Cloudflare come CDN. Il vantaggio è che tutto funziona via API, senza toccare la configurazione del web server:

# Esporta le credenziali Cloudflare
export CF_Token="il_tuo_api_token_cloudflare"
export CF_Email="tuaemail@esempio.it"

# Emetti un wildcard certificate
acme.sh --issue -d esempio.it -d '*.esempio.it' --dns dns_cf

Installazione del Certificato e Reload Automatico

Dopo l’emissione, i certificati vanno copiati nella posizione corretta per Nginx o Apache. Questo è un passaggio critico che all’inizio ho sbagliato: non usare mai direttamente i file dalla cartella ~/.acme.sh/, perché la struttura interna può cambiare. Usa sempre --install-cert:

# Installazione per Nginx
acme.sh --install-cert -d esempio.it 
  --key-file /etc/ssl/esempio.it/key.pem 
  --fullchain-file /etc/ssl/esempio.it/fullchain.pem 
  --reloadcmd "systemctl reload nginx"

# Installazione per Apache
acme.sh --install-cert -d esempio.it 
  --cert-file /etc/ssl/esempio.it/cert.pem 
  --key-file /etc/ssl/esempio.it/key.pem 
  --fullchain-file /etc/ssl/esempio.it/fullchain.pem 
  --reloadcmd "systemctl reload apache2"

Il parametro --reloadcmd è fondamentale: senza di esso il certificato viene rinnovato ma il web server continua a servire quello vecchio. Ho perso un’ora a debuggare questo problema la prima volta.

Monitoraggio e Notifiche: Non Fidarti Solo dell’Automazione

Anche con l’automazione perfettamente configurata, ho imparato che serve un livello di monitoraggio indipendente. Let’s Encrypt ha smesso di inviare email di promemoria per i certificati in scadenza, quindi devi arrangiarti.

Script di Monitoraggio con OpenSSL

Ho creato questo semplice script Bash che gira via cronjob e mi avvisa se un certificato scade entro i prossimi 14 giorni:

#!/bin/bash
# check_ssl_expiry.sh - Controlla la scadenza SSL dei domini

DOMAINS=("esempio.it" "altrosito.it" "shop.esempio.it")
ALERT_DAYS=14

for DOMAIN in "${DOMAINS[@]}"; do
  EXPIRY=$(echo | openssl s_client -servername "$DOMAIN" -connect "$DOMAIN":443 2>/dev/null 
    | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
  
  if [ -n "$EXPIRY" ]; then
    EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s)
    NOW_EPOCH=$(date +%s)
    DAYS_LEFT=$(( (EXPIRY_EPOCH - NOW_EPOCH) / 86400 ))
    
    if [ "$DAYS_LEFT" -lt "$ALERT_DAYS" ]; then
      echo "ATTENZIONE: $DOMAIN scade tra $DAYS_LEFT giorni ($EXPIRY)" 
        | mail -s "SSL Alert: $DOMAIN" admin@esempio.it
    fi
  fi
done

# Aggiungi al crontab per esecuzione giornaliera
0 8 * * * /opt/scripts/check_ssl_expiry.sh

Se utilizzi Grafana e Prometheus per il monitoraggio server, puoi anche configurare un exporter SSL per avere dashboard e alerting integrati.

Automazione SSL su Plesk: Cosa Cambia con i Nuovi Certificati

Chi come me ha gestito server Plesk sa che il pannello integra Let’s Encrypt nativamente tramite l’estensione dedicata. Tuttavia, con le novità del 2026, ci sono alcune accortezze importanti. Se stai valutando alternative a Plesk per contenere i costi, ho scritto una guida completa su come affrontare l’aumento prezzi Plesk 2026 con alternative open source.

Su Plesk, il rinnovo SSL è gestito automaticamente dall’estensione, ma vi consiglio comunque di:

Verificare che l’estensione Let’s Encrypt sia aggiornata all’ultima versione
Controllare i cronjob di Plesk per assicurarvi che il task di rinnovo sia attivo
Monitorare i log in /var/log/plesk/ per errori di rinnovo

Best Practice per il Rinnovo Automatico dei Certificati SSL nel 2026

Dopo anni di esperienza, ecco le regole d’oro che seguo:

Non hardcodare gli intervalli di rinnovo: con la riduzione a 45 giorni, un intervallo fisso di 60 giorni non funzionerà più. Usa i meccanismi di rinnovo automatico dei client ACME
Abilita ACME Renewal Information (ARI): questo protocollo permette a Let’s Encrypt di comunicare al tuo client quando è il momento ottimale per rinnovare
Testa sempre con –dry-run: prima di mettere in produzione qualsiasi modifica alla configurazione SSL
Monitora indipendentemente: non fidarti solo del client ACME, usa uno script esterno o un servizio di monitoraggio
Randomizza gli orari di rinnovo: evita di rinnovare a mezzanotte UTC o al primo secondo di ogni ora, perché sovraccarichi i server Let’s Encrypt
Prepara l’infrastruttura per certificati più brevi: se usi reverse proxy, CDN o load balancer, assicurati che la distribuzione e il reload dei certificati siano automatizzati end-to-end

Se gestisci configurazioni con reverse proxy Nginx per più siti, assicurati che il reload del certificato venga propagato correttamente a tutti i virtual host.

Certbot vs ACME.sh: Quale Scegliere?

Nella mia esperienza, la scelta dipende dal contesto:

Certbot: ideale su server Ubuntu/Debian con Nginx o Apache, installazione via Snap con aggiornamenti automatici, ottimo per chi vuole una soluzione “set and forget”
acme.sh: perfetto su server minimali, container, IoT o quando serve integrazione DNS API per wildcard. Zero dipendenze, funziona ovunque ci sia una shell

Personalmente uso Certbot sui server di produzione con Nginx e acme.sh per i wildcard e le configurazioni più complesse. Non c’è una risposta giusta per tutti: l’importante è che il rinnovo sia automatico e monitorato.

FAQ

Quando Let’s Encrypt ridurrà la validità dei certificati a 45 giorni?

La riduzione avverrà in fasi: a maggio 2026 il profilo tlsserver passerà a 45 giorni (opt-in), a febbraio 2027 il profilo di default scenderà a 64 giorni, e a febbraio 2028 tutti i certificati di default saranno a 45 giorni. Se la tua automazione funziona correttamente, non dovrai fare nulla di speciale.

Posso usare sia Certbot che acme.sh sullo stesso server?

Tecnicamente sì, ma lo sconsiglio fortemente: avere due client ACME attivi sullo stesso server può causare conflitti, rinnovi duplicati e problemi con i rate limit di Let’s Encrypt. Scegli uno dei due e usalo per tutti i domini del server.

Cosa sono i certificati short-lived da 6 giorni di Let’s Encrypt?

Sono certificati validi solo 160 ore (circa 6 giorni), disponibili dal gennaio 2026 selezionando il profilo shortlived nel client ACME. Non includono informazioni di revoca (OCSP/CRL) perché scadono troppo rapidamente. Sono consigliati solo se hai un’automazione di rinnovo completamente affidabile, dato che il client ACME dovrebbe girare almeno una volta al giorno.

Come verifico quando scade il mio certificato SSL attuale?

Puoi usare OpenSSL direttamente da terminale: echo | openssl s_client -servername tuodominio.it -connect tuodominio.it:443 2>/dev/null | openssl x509 -noout -dates. Questo ti mostra le date di emissione e scadenza del certificato attualmente in uso.

Il rinnovo automatico funziona anche dietro Cloudflare o un reverse proxy?

Sì, ma con alcune accortezze. Se usi Cloudflare con proxy attivo, la validazione HTTP-01 potrebbe non funzionare: in quel caso usa la validazione DNS-01 con le API di Cloudflare, sia su Certbot (con il plugin certbot-dns-cloudflare) che su acme.sh (con --dns dns_cf). Nella mia esperienza, la DNS validation è sempre la più affidabile in queste configurazioni.

Conclusione: Non Restare Mai con un Certificato SSL Scaduto

Automatizzare il rinnovo dei certificati SSL/TLS nel 2026 non è più un lusso da sysadmin esperti: con Let’s Encrypt che riduce la validità a 45 giorni e introduce certificati da 6 giorni, è una competenza fondamentale per chiunque gestisca un server. Che tu scelga Certbot per la sua semplicità o acme.sh per la sua flessibilità, l’importante è che il rinnovo sia completamente automatico, il reload del web server sia integrato nel processo, e un sistema di monitoraggio indipendente ti avvisi in caso di problemi.

Nella mia esperienza, investire un’ora per configurare correttamente l’automazione SSL ti risparmia decine di ore di troubleshooting e — soprattutto — ti evita quella telefonata alle 3 di notte perché il sito del cliente è down per un certificato scaduto.

Hai domande sulla configurazione dei tuoi certificati SSL? Lascia un commento qui sotto e ti aiuto volentieri!