Nel 2026 servire un sito senza HTTPS significa perdere visitatori, posizionamento e fiducia. La buona notizia: un certificato TLS valido non costa più nulla. Let’s Encrypt ha emesso oltre 7 miliardi di certificati dal 2015 e oggi protegge circa 762 milioni di siti web, secondo il rapporto annuale 2025 di ISRG. Lo strumento che rende tutto questo automatico si chiama Certbot, mantenuto dalla Electronic Frontier Foundation. Questo tutorial ti porta da un server Nginx in chiaro a un sito con HTTPS, redirect forzato, rinnovo automatico e header di sicurezza, in 10 step verificabili.

Il percorso richiede circa 30 minuti su un server pulito. Useremo Ubuntu 24.04 LTS e Nginx, il plugin --nginx di Certbot, l’ambiente di staging per i test e un systemd timer per il rinnovo. Ogni comando include l’output atteso, e alla fine trovi 6 errori comuni, 8 voci di troubleshooting e una configurazione di produzione completa che puoi copiare. Il 2026 porta novità importanti: certificati a vita breve da 6 giorni, profili ACME nominati e il passaggio del profilo tlsserver a 45 giorni di validità dal 13 maggio 2026. Le copriamo tutte.

Perché Let’s Encrypt domina l’HTTPS gratuito nel 2026

Let’s Encrypt è oggi la più grande autorità di certificazione al mondo per volume di emissione. I numeri parlano chiaro: più di 7 miliardi di certificati emessi dal lancio nel 2015 e una copertura di 762 milioni di siti web nel rapporto 2025. Dietro il progetto c’è ISRG (Internet Security Research Group), un’organizzazione no-profit la cui missione è rendere l’HTTPS gratuito, automatico e accessibile a chiunque. Questo modello ha cambiato il web: nel 2015 cifrare un sito richiedeva centinaia di euro l’anno, oggi richiede un comando.

Il 2026 segna una svolta verso i certificati a vita breve. Il modello classico da 90 giorni resta la base nel rapporto 2025, ma ISRG ha già lanciato nel 2025 un’opzione di certificati da 6 giorni e introdotto i certificati per indirizzi IP. Dal 13 maggio 2026, il profilo ACME tlsserver emette certificati con validità predefinita di 45 giorni. La logica è di sicurezza: una validità più corta riduce la finestra di abuso di una chiave compromessa e costringe all’automazione. Per te questo significa una sola cosa, il rinnovo automatico non è opzionale, è il cuore di qualsiasi configurazione seria con Certbot.

C’è un’altra novità operativa che cambia le abitudini: dal giugno 2025 Let’s Encrypt ha interrotto l’invio delle email di notifica di scadenza. Per anni quelle email sono state la rete di sicurezza di chi rinnovava a mano. Ora non esistono più. Se il tuo rinnovo automatico si rompe, nessuno ti avvisa via email: il sito smette di funzionare e basta. Questo rende il monitoraggio del rinnovo (lo affrontiamo allo step 8) una parte obbligatoria del lavoro, non un extra. ISRG ha anche annunciato che nel 2026 deprecherà l’EKU di Client Authentication per allinearsi ai nuovi requisiti dei root program, quindi i certificati Let’s Encrypt vanno usati solo come certificati server, mai come certificati client.

Se vuoi capire cosa accade davvero quando un browser apre una connessione cifrata, il nostro approfondimento su come HTTPS e TLS proteggono una connessione spiega l’handshake passo per passo. Qui ci concentriamo sulla pratica: ottenere e mantenere il certificato.

Come funziona il protocollo ACME dietro Certbot

Prima di lanciare comandi conviene capire cosa fa Certbot sotto il cofano. Certbot è un client del protocollo ACME (Automatic Certificate Management Environment), standardizzato nell’RFC 8555. ACME automatizza il dialogo tra il tuo server e l’autorità di certificazione. Quando chiedi un certificato, Certbot crea un account presso Let’s Encrypt, invia una richiesta per i domini che vuoi proteggere e riceve una o più sfide (challenge) da risolvere. Risolvendo la sfida dimostri di controllare davvero quel dominio. Solo allora Let’s Encrypt firma ed emette il certificato.

Esistono tre tipi di sfida, e scegliere quella giusta evita metà dei problemi:

  • HTTP-01: Certbot crea un file token sotto /.well-known/acme-challenge/ e Let’s Encrypt lo legge via HTTP sulla porta 80. È la sfida predefinita, perfetta per un singolo dominio o sottodominio.
  • DNS-01: dimostri il controllo creando un record TXT nel DNS. È l’unica sfida che permette i certificati wildcard (ad esempio *.esempio.it) e funziona anche senza esporre la porta 80.
  • TLS-ALPN-01: la validazione avviene sulla porta 443 tramite l’estensione ALPN del TLS. Utile dietro reverse proxy o quando la porta 80 è occupata.

Nel 2026 ACME introduce anche i profili nominati. La pagina delle catene di certificati di Let’s Encrypt elenca profili come classic, tlsserver e tlsclient. Il profilo determina la validità e il tipo d’uso del certificato. Il profilo classic mantiene i 90 giorni storici, mentre tlsserver passa ai 45 giorni dal 13 maggio 2026. Certbot seleziona un profilo predefinito sensato, ma è bene sapere che esistono perché influenzano la frequenza dei rinnovi.

Un’ultima nota sulle chiavi. Let’s Encrypt raccomanda chiavi ECDSA dove possibile, pur continuando a supportare RSA. I certificati subscriber ECDSA vengono emessi da intermediari ECDSA, quelli RSA da intermediari RSA. ECDSA offre la stessa sicurezza con chiavi molto più corte e handshake più veloci. Confronteremo le due opzioni più avanti. Se vuoi un ripasso sui fondamenti, la nostra guida alle firme digitali e al ruolo delle funzioni hash chiarisce perché ECDSA è così efficiente.

Prerequisiti e versioni richieste

Questo tutorial parte da un server Linux pubblico con un dominio puntato sul suo indirizzo IP. Non servono competenze avanzate di sistemista, ma serve accesso root o un utente con sudo. La tabella seguente riassume tutto ciò che ti occorre prima di iniziare. Dove non posso garantire un numero di versione esatto e attuale, indico “ultima versione”: installa sempre il pacchetto più recente disponibile per la tua distribuzione.

RequisitoVersione consigliataNote
Sistema operativoUbuntu 24.04 LTSFunziona anche su Debian 12, Rocky Linux 9, AlmaLinux 9
Web serverNginx 1.24 o superioreApache 2.4 va bene con il plugin --apache
CertbotUltima versione (via snap)Lo snap si aggiorna da solo, evita pacchetti apt obsoleti
snapdUltima versionePreinstallato su Ubuntu, da installare su Debian
DominioRecord DNS A o AAAA validoDeve puntare all’IP pubblico del server
Porte aperte80 e 443 in ingressoLa 80 serve alla sfida HTTP-01 e al redirect
Accessoroot o utente con sudoPer installare pacchetti e scrivere in /etc/nginx
OpenSSLOpenSSL 3.xPer ispezionare i certificati emessi

Verifica due cose prima di proseguire. Primo, che il dominio risolva davvero al tuo server: un record DNS sbagliato è la causa numero uno dei fallimenti della sfida HTTP-01. Secondo, che il firewall lasci passare la porta 80, perché Let’s Encrypt deve raggiungere il tuo server dall’esterno per validare il dominio. Se gestisci chiavi e certificati anche a livello locale, il nostro tutorial su OpenSSL 3.5 LTS per chiavi e certificati copre la generazione manuale, complementare a quanto vedremo qui con Certbot.

Step 1-2: Preparare server, DNS e firewall

Il primo passo è assicurarsi che il sistema sia aggiornato e che Nginx serva già il dominio in HTTP. Senza un server block funzionante, il plugin --nginx non sa dove inserire la configurazione TLS. Aggiorna i pacchetti e installa Nginx:

# Step 1: aggiornamento del sistema e installazione di Nginx
sudo apt update && sudo apt upgrade -y
sudo apt install -y nginx

# Apri le porte 80 e 443 sul firewall UFW
sudo ufw allow 'Nginx Full'
sudo ufw reload
sudo ufw status

Ora crea un server block minimo per il tuo dominio. Sostituisci esempio.it con il tuo dominio reale ovunque compaia. Questo file dice a Nginx a quale dominio risponde, informazione che Certbot leggerà per inserire il certificato giusto.

# Step 2: server block HTTP in /etc/nginx/sites-available/esempio.it
server {
    listen 80;
    listen [::]:80;
    server_name esempio.it www.esempio.it;

    root /var/www/esempio.it/html;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Attiva il sito, testa la sintassi e ricarica Nginx. Il test di sintassi è un’abitudine che salva: Nginx non si ricarica mai con una configurazione rotta, ma è meglio scoprirlo subito.

sudo ln -s /etc/nginx/sites-available/esempio.it /etc/nginx/sites-enabled/
sudo nginx -t
# Output atteso:
# nginx: configuration file /etc/nginx/nginx.conf test is successful
sudo systemctl reload nginx

Verifica dal tuo computer che il dominio risponda in HTTP prima di chiedere il certificato. Un semplice curl -I http://esempio.it deve restituire HTTP/1.1 200 OK. Se ricevi un timeout, il problema è il DNS o il firewall, non Certbot. Risolvi qui, perché la sfida HTTP-01 fallirà esattamente per gli stessi motivi. Controlla la propagazione del DNS con dig esempio.it +short: l’output deve mostrare l’IP pubblico del tuo server.

Step 3: Installare Certbot con snap su Ubuntu

Per anni la via comune era apt install certbot, ma quel pacchetto invecchia in fretta nei repository delle distribuzioni. La documentazione attuale di Certbot raccomanda l’installazione via snap, perché lo snap si aggiorna da solo e ti dà sempre l’ultima versione. Questo conta nel 2026, quando i profili ACME e i certificati a vita breve cambiano spesso. Se hai un vecchio Certbot installato via apt, rimuovilo prima per evitare conflitti.

# Step 3: rimuovi eventuali installazioni apt obsolete
sudo apt remove certbot -y

# Assicurati che snapd sia aggiornato
sudo snap install core
sudo snap refresh core

# Installa Certbot dallo snap classico
sudo snap install --classic certbot

# Crea il link simbolico per avere il comando nel PATH
sudo ln -s /snap/bin/certbot /usr/bin/certbot

# Verifica la versione installata
certbot --version
# Output atteso (esempio):
# certbot 3.x.x

Il numero di versione esatto dipende dal momento in cui installi: lo snap ti dà sempre l’ultima release stabile, quindi non fissare una versione nei tuoi script. Se il comando certbot --version restituisce un numero, l’installazione è riuscita. Se restituisce “command not found”, il link simbolico non è stato creato: ripeti la riga ln -s.

Su distribuzioni senza snap preinstallato (Debian, alcune immagini cloud minimali) installa prima snapd con sudo apt install snapd e riavvia la sessione. In alternativa, su sistemi dove snap non è praticabile, esiste l’installazione via pip in un ambiente virtuale, ma perde l’aggiornamento automatico ed è sconsigliata per la produzione. La documentazione ufficiale di Certbot mantenuta dalla EFF elenca le istruzioni per ogni combinazione di sistema e web server.

Step 4-5: Testare in staging e ottenere il certificato

Qui sta la differenza tra un professionista e chi brucia i propri limiti di rate. Let’s Encrypt offre un ambiente di staging che emette certificati non fidati dai browser ma identici nel processo. Usalo per provare l’automazione senza consumare i limiti di produzione. Il flag --dry-run esegue tutta la procedura senza salvare nulla, ed è il test più rapido.

# Step 4: prova a secco contro l'ambiente di staging
sudo certbot certonly --nginx --dry-run -d esempio.it -d www.esempio.it

# Output atteso in caso di successo:
# The dry run was successful.
# Congratulations, all simulated renewals succeeded

Se la prova a secco riesce, sei pronto per la produzione. Lancia Certbot con il plugin Nginx: il plugin ottiene il certificato e modifica automaticamente il server block per servire HTTPS. La prima volta Certbot chiede un’email (per i recuperi account, non più per le notifiche di scadenza che sono state interrotte) e l’accettazione dei termini di servizio.

# Step 5: emissione del certificato di produzione con plugin Nginx
sudo certbot --nginx -d esempio.it -d www.esempio.it

# Certbot chiede:
# 1) un indirizzo email per il ripristino dell'account
# 2) accettazione dei Terms of Service (A)
# 3) se vuoi il redirect automatico HTTP -> HTTPS (consigliato: opzione 2)

Quando Certbot chiede del redirect, scegli l’opzione che reindirizza tutto il traffico HTTP verso HTTPS. È il modo più semplice per non lasciare buchi in chiaro. Se preferisci controllare la configurazione a mano, scegli “no redirect” e lo aggiungiamo manualmente allo step 7. Per chi gestisce dati sensibili e deve rispettare la direttiva NIS2 in Italia, la cifratura del traffico in transito è uno dei controlli di base richiesti.

Step 6-7: Verificare l’output e forzare il redirect HTTPS

Dopo l’emissione, Certbot stampa il percorso dei file e la data di scadenza. Conoscere questi percorsi è importante: sono i file che Nginx serve e che gli script di rinnovo aggiornano. Questo è l’output tipico di un’emissione riuscita.

# Step 6: output tipico di un'emissione riuscita
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/esempio.it/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/esempio.it/privkey.pem
This certificate expires on 2026-09-11.
Deploying certificate
Successfully deployed certificate for esempio.it to /etc/nginx/sites-enabled/esempio.it
Congratulations! You have successfully enabled HTTPS on https://esempio.it

I due file chiave sono fullchain.pem (il tuo certificato più la catena intermedia) e privkey.pem (la chiave privata). Non spostarli e non modificarli a mano: Certbot li gestisce e li sovrascrive al rinnovo. La cartella live contiene link simbolici sempre aggiornati, quindi punta sempre lì nella configurazione di Nginx, mai alle cartelle archive numerate.

Se hai scelto di non far gestire il redirect a Certbot, ecco la configurazione manuale. Il primo blocco reindirizza tutto l’HTTP verso HTTPS, il secondo serve il sito cifrato con TLS 1.3 e TLS 1.2 (le uniche versioni che dovresti supportare nel 2026).

# Step 7: redirect e configurazione TLS in /etc/nginx/sites-available/esempio.it
server {
    listen 80;
    listen [::]:80;
    server_name esempio.it www.esempio.it;
    # Reindirizza ogni richiesta HTTP a HTTPS con codice 301 permanente
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name esempio.it www.esempio.it;

    ssl_certificate     /etc/letsencrypt/live/esempio.it/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/esempio.it/privkey.pem;

    # Limita ai protocolli moderni
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;

    root /var/www/esempio.it/html;
    index index.html;
}

Dopo ogni modifica esegui sempre sudo nginx -t && sudo systemctl reload nginx. Poi prova il sito su SSL Labs SSL Test: un punteggio A o A+ conferma che protocolli e catena sono corretti. Apri il sito nel browser e controlla che il lucchetto sia presente e che http:// rediriga a https://.

Step 8: Automatizzare il rinnovo dei certificati

Questo è lo step più importante del 2026. Con la fine delle email di scadenza e l’arrivo di certificati da 45 giorni e perfino da 6 giorni, il rinnovo manuale è impraticabile. Per fortuna l’installazione via snap di Certbot configura già un systemd timer che tenta il rinnovo due volte al giorno. Il comando certbot renew rinnova solo i certificati che scadono entro 30 giorni, quindi puoi eseguirlo spesso senza rischi. Verifica che il timer esista e sia attivo.

# Step 8: verifica il systemd timer del rinnovo
systemctl list-timers | grep certbot
# Output atteso (esempio):
# snap.certbot.renew.timer  ... snap.certbot.renew.service

# Simula un rinnovo senza eseguirlo davvero
sudo certbot renew --dry-run
# Output atteso:
# Congratulations, all simulated renewals succeeded

Se il tuo sistema non usa systemd, configura un cron job. Aggiungi questa riga con sudo crontab -e per tentare il rinnovo ogni giorno e ricaricare Nginx solo quando un certificato cambia davvero:

# Alternativa cron: rinnovo giornaliero con reload condizionato di Nginx
0 3 * * * certbot renew --quiet --deploy-hook "systemctl reload nginx"

Il --deploy-hook è la parte che molti dimenticano. Senza di esso Nginx continua a servire il vecchio certificato in memoria anche dopo il rinnovo, finché non lo ricarichi. L’hook ricarica Nginx solo quando un certificato è stato effettivamente rinnovato, evitando reload inutili. Dato che nessuno ti avvisa più via email se il rinnovo fallisce, aggiungi un monitoraggio esterno: un servizio di uptime che controlla la data di scadenza del certificato e ti avvisa con 7 giorni di anticipo è la migliore assicurazione.

Step 9: Emettere certificati wildcard con DNS-01

Quando hai molti sottodomini (app.esempio.it, api.esempio.it, blog.esempio.it) un certificato wildcard *.esempio.it ti evita di gestirli uno a uno. C’è un solo modo per ottenerlo: la sfida DNS-01. Let’s Encrypt non emette wildcard tramite HTTP-01 o TLS-ALPN-01, perché un wildcard copre sottodomini infiniti e l’unica prova accettabile è il controllo del DNS della zona. Devi quindi creare un record TXT, manualmente o tramite un plugin del tuo provider DNS.

# Step 9: certificato wildcard con sfida DNS-01 manuale
sudo certbot certonly --manual --preferred-challenges dns \
  -d esempio.it -d "*.esempio.it"

# Certbot mostra un valore da inserire come record TXT:
# _acme-challenge.esempio.it  TXT  "il-valore-da-copiare-nel-DNS"
# Crea il record, attendi la propagazione, poi premi Invio per continuare

La modalità --manual va bene per un test, ma non si rinnova da sola: ad ogni rinnovo dovresti aggiornare il record TXT a mano. Per la produzione usa un plugin DNS automatizzato. Certbot offre plugin ufficiali per molti provider (Cloudflare, Route 53, Google Cloud DNS, OVH e altri). Con il plugin Cloudflare, ad esempio, salvi un token API in un file protetto e Certbot crea e cancella il record TXT da solo, rendendo anche i wildcard completamente automatici.

# Esempio con plugin DNS automatizzato (Cloudflare)
sudo snap set certbot trust-plugin-with-root=ok
sudo snap install certbot-dns-cloudflare

# File credenziali con permessi restrittivi (chmod 600)
echo "dns_cloudflare_api_token = IL_TUO_TOKEN" | sudo tee /root/.cloudflare.ini
sudo chmod 600 /root/.cloudflare.ini

sudo certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials /root/.cloudflare.ini \
  -d esempio.it -d "*.esempio.it"

Attenzione ai permessi del file delle credenziali: un token API DNS dà controllo sulla tua zona, quindi chmod 600 e proprietà root sono obbligatori. Un token esposto equivale a consegnare le chiavi del dominio. I dettagli sui tipi di sfida e sui requisiti dei wildcard sono nella documentazione ufficiale sui tipi di sfida.

Step 10: HSTS e header di sicurezza in Nginx

HTTPS funzionante è il minimo, non il traguardo. Un attaccante può ancora tentare un downgrade verso HTTP se il primo accesso dell’utente avviene in chiaro. La risposta è HSTS (HTTP Strict Transport Security), un header che dice al browser di usare solo HTTPS per quel dominio per un periodo definito. Aggiungilo solo dopo aver confermato che HTTPS è stabile, perché HSTS blocca l’accesso in chiaro e un errore può rendere il sito irraggiungibile fino alla scadenza dell’header.

# Step 10: header di sicurezza nel blocco server 443 di Nginx
# HSTS: forza HTTPS per 1 anno, inclusi i sottodomini
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

# Impedisce il caricamento del sito in iframe di terzi (anti-clickjacking)
add_header X-Frame-Options "SAMEORIGIN" always;

# Blocca lo sniffing del MIME type
add_header X-Content-Type-Options "nosniff" always;

# Controlla quali informazioni di referrer vengono inviate
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Dopo aver inserito gli header, esegui di nuovo sudo nginx -t && sudo systemctl reload nginx e ricontrolla con SSL Labs e con gli strumenti per sviluppatori del browser (scheda Network, intestazioni di risposta). Quando sei sicuro che tutto sia stabile da settimane, puoi valutare l’inserimento del dominio nella lista di preload HSTS, una decisione difficile da annullare. La parola always garantisce che gli header siano presenti anche nelle risposte di errore, non solo nelle 200. A questo punto hai un progetto completo e funzionante: HTTPS gratuito, redirect forzato, rinnovo automatico, supporto wildcard e header di sicurezza moderni.

I limiti di rate di Let’s Encrypt da conoscere

Let’s Encrypt è gratuito ma non illimitato. I limiti di rate proteggono il servizio dagli abusi e penalizzano chi sbaglia in produzione invece di testare in staging. Superare un limite significa attendere ore o giorni prima di poter emettere di nuovo, e durante l’attesa il sito resta senza certificato. Ecco i limiti principali che ogni configurazione deve rispettare, secondo la documentazione ufficiale.

LimiteValoreReintegro
Certificati per dominio registrato50 ogni 7 giorni1 ogni 202 minuti
Certificati duplicati (stesso set di identificatori)5 ogni 7 giorni1 ogni 34 ore
Ambiente di stagingLimiti molto più altiPer i test prima della produzione
Domini per certificato (SAN)Fino a 100 nomiPer richiesta

La trappola più comune è il limite dei certificati duplicati: 5 emissioni per lo stesso identico set di domini ogni 7 giorni. Se lanci Certbot in produzione cinque volte di fila per provare qualcosa, hai esaurito il limite e devi aspettare. È esattamente per questo che lo step 4 insiste sul --dry-run e sullo staging. Il limite di 50 certificati per dominio registrato a settimana raramente disturba un singolo sito, ma può bloccare chi gestisce molti sottodomini con certificati separati: in quel caso un singolo certificato wildcard risolve il problema. La documentazione completa è su letsencrypt.org/docs/rate-limits.

ECDSA o RSA: quale chiave scegliere

Quando Certbot emette un certificato genera una coppia di chiavi. Il tipo di chiave influenza prestazioni e compatibilità. Let’s Encrypt raccomanda ECDSA dove possibile, e nel 2026 questa è la scelta giusta per la quasi totalità dei siti. ECDSA offre la stessa robustezza crittografica di RSA con chiavi molto più corte: una chiave ECDSA P-256 equivale grosso modo a una RSA da 3072 bit, ma con handshake più rapidi e meno carico sulla CPU del server.

CaratteristicaECDSA (P-256)RSA (2048/3072)
Dimensione chiave256 bit2048 o 3072 bit
Velocità handshakePiù velocePiù lenta
Carico CPU serverBassoPiù alto
Compatibilità client molto vecchiBuona (client moderni)Massima
Raccomandazione Let’s EncryptPreferitaSupportata

Per forzare una chiave ECDSA aggiungi --key-type ecdsa al comando Certbot. Scegli RSA solo se devi servire client molto datati che non supportano le curve ellittiche, una casistica ormai marginale. Se vuoi capire perché le curve ellittiche permettono chiavi così corte, la nostra spiegazione delle funzioni hash crittografiche e dei fondamenti matematici della crittografia moderna fornisce il contesto. La direzione del settore è chiara: ECDSA oggi, e algoritmi resistenti ai computer quantistici nei prossimi anni.

6 errori comuni da evitare con Certbot

La maggior parte dei fallimenti con Certbot nasce da pochi errori ricorrenti. Conoscerli in anticipo ti fa risparmiare ore.

  • Saltare lo staging e bruciare i limiti. Lanciare Certbot in produzione per “provare” esaurisce il limite di 5 certificati duplicati a settimana. Usa sempre --dry-run prima.
  • Porta 80 chiusa. La sfida HTTP-01 richiede che Let’s Encrypt raggiunga il server sulla porta 80. Un firewall cloud o UFW che la blocca fa fallire la validazione con un errore di connessione.
  • DNS non propagato. Chiedere un certificato subito dopo aver creato il record A, prima che il DNS si propaghi, produce un fallimento della sfida. Verifica con dig prima di lanciare Certbot.
  • Puntare ai file in archive invece che in live. Nginx deve puntare a /etc/letsencrypt/live/dominio/. Le cartelle archive numerate cambiano ad ogni rinnovo e rompono la configurazione.
  • Dimenticare il deploy-hook. Senza ricaricare Nginx dopo il rinnovo, il server continua a servire il vecchio certificato finché non lo riavvii a mano.
  • Attivare HSTS troppo presto. Inserire HSTS con max-age lungo prima che HTTPS sia stabile può rendere il sito irraggiungibile per i visitatori per mesi.

C’è un settimo errore che merita una menzione: affidarsi alle email di scadenza. Non esistono più dal giugno 2025. Se la tua procedura mentale era “rinnovo quando arriva l’email”, aggiornala subito con un monitoraggio attivo.

Troubleshooting: 8 problemi risolti

Quando qualcosa va storto, l’errore di Certbot di solito indica la causa. Questa tabella raccoglie i problemi più frequenti e la soluzione diretta.

Problema / erroreCausa probabileSoluzione
“Timeout during connect” nella sfida HTTP-01Porta 80 chiusa o firewall cloudApri la porta 80 in ingresso su UFW e sul pannello del provider
“DNS problem: NXDOMAIN”Record DNS assente o non propagatoCrea il record A e verifica con dig dominio +short
“Too many certificates already issued”Limite di rate superatoAttendi il reintegro o passa allo staging per i test
“command not found: certbot”Link simbolico snap mancanteEsegui sudo ln -s /snap/bin/certbot /usr/bin/certbot
Nginx serve ancora il vecchio certificatoManca il reload dopo il rinnovoAggiungi --deploy-hook "systemctl reload nginx"
“Could not automatically find a matching server block”Manca server_name nel blocco NginxAggiungi la direttiva server_name dominio e ricarica
Wildcard rifiutato con HTTP-01I wildcard richiedono DNS-01Usa --preferred-challenges dns o un plugin DNS
Errore “unauthorized” durante la validazioneFile challenge servito da un altro virtual hostVerifica che il dominio risponda al server block corretto

Per qualsiasi errore non elencato, esegui Certbot con il flag -v per l’output verboso e controlla il log in /var/log/letsencrypt/letsencrypt.log. Quel file contiene quasi sempre la risposta esatta del server ACME, che è la fonte più affidabile sulla causa del fallimento.

Consigli avanzati per la produzione

Una volta che HTTPS funziona, alcune scelte separano un setup amatoriale da uno pronto per la produzione. Prima: testa il rinnovo in modo aggressivo. Esegui certbot renew --dry-run dopo ogni modifica importante a Nginx, perché un cambiamento alla configurazione può rompere silenziosamente il rinnovo automatico, e con i certificati a vita breve del 2026 il margine d’errore è minimo.

Seconda: valuta la stapling OCSP per ridurre la latenza dell’handshake, attivabile in Nginx con ssl_stapling on e ssl_stapling_verify on. Terza: per più server dietro un load balancer, centralizza l’emissione su un nodo e distribuisci i certificati, oppure usa la sfida DNS-01 che non dipende dal nodo che riceve il traffico. Quarta: tieni d’occhio i profili ACME. Con il passaggio del profilo tlsserver a 45 giorni dal 13 maggio 2026, verifica quale profilo usa la tua versione di Certbot e regola il monitoraggio di conseguenza. La documentazione HTTPS di Nginx e l’RFC 8555 che definisce ACME restano i riferimenti tecnici da tenere a portata di mano.

Quinta, sul fronte sicurezza: combina HTTPS con altre difese. Un certificato valido protegge i dati in transito ma non sostituisce password robuste e secondo fattore. La nostra guida alla sicurezza delle password, hashing e secondo fattore copre il livello applicativo. Per il quadro completo delle minacce e delle contromisure, parti dal nostro hub sulla sicurezza online. HTTPS è la base, non l’intera fortezza.

Domande frequenti su Let’s Encrypt e Certbot

Let’s Encrypt è davvero gratuito anche per uso commerciale?

Sì. I certificati di Let’s Encrypt sono gratuiti per qualsiasi uso, incluso quello commerciale, senza limiti sul numero di siti oltre ai normali limiti di rate. Il progetto è finanziato da ISRG, organizzazione no-profit, e dai suoi sponsor. Non c’è un piano a pagamento e non c’è un upsell.

Cosa succede se dimentico di rinnovare il certificato?

Il certificato scade e i browser mostrano un avviso di sicurezza che blocca l’accesso al sito. Dal giugno 2025 Let’s Encrypt non invia più email di scadenza, quindi nessuno ti avvisa. Con il rinnovo automatico via systemd timer o cron e un monitoraggio esterno della scadenza, questo scenario non dovrebbe verificarsi.

Quanto durano i certificati di Let’s Encrypt nel 2026?

Il certificato classico dura 90 giorni. Nel 2025 è stata introdotta un’opzione a vita breve da 6 giorni, e dal 13 maggio 2026 il profilo tlsserver emette certificati con validità predefinita di 45 giorni. In tutti i casi il rinnovo automatico gestisce la durata senza che tu debba intervenire.

Posso ottenere un certificato wildcard con Certbot?

Sì, ma solo tramite la sfida DNS-01. Let’s Encrypt non emette certificati wildcard tramite HTTP-01 o TLS-ALPN-01. Per un rinnovo automatico dei wildcard serve un plugin DNS del tuo provider (Cloudflare, Route 53 e altri) che crei e cancelli il record TXT in automatico.

Certbot funziona anche con Apache o solo con Nginx?

Funziona con entrambi. Per Nginx si usa il flag --nginx, per Apache il flag --apache. Esiste anche la modalità certonly che ottiene solo il certificato senza toccare la configurazione del web server, utile dietro reverse proxy o con web server non supportati direttamente dai plugin.

Devo usare ECDSA o RSA per il certificato?

Usa ECDSA, raccomandata da Let’s Encrypt e ideale per la quasi totalità dei siti nel 2026. Offre handshake più veloci e minor carico CPU rispetto a RSA, con la stessa sicurezza. Scegli RSA solo se devi servire client molto datati senza supporto per le curve ellittiche.

Lo staging serve davvero o posso saltarlo?

Serve, soprattutto durante i test. L’ambiente di staging ha limiti di rate molto più alti e ti permette di provare l’automazione senza consumare i 5 certificati duplicati a settimana della produzione. Il modo più rapido è il flag --dry-run, che simula tutto il processo senza salvare nulla.

Quanti certificati ha emesso Let’s Encrypt finora?

Oltre 7 miliardi dal lancio nel 2015, secondo il rapporto annuale 2025 di ISRG, con una copertura di circa 762 milioni di siti web. Questo rende Let’s Encrypt la più grande autorità di certificazione al mondo per volume di emissione.

Fonti esterne: Let’s Encrypt, Certbot (EFF), tipi di sfida ACME, RFC 8555 (ACME), documentazione HTTPS di Nginx, annuncio certificati a 6 giorni e IP.