Certificato HTTPS gratis con Let’s Encrypt e Certbot: installazione, rinnovo e wildcard

Let’s Encrypt rilascia certificati HTTPS gratuiti, e Certbot è il client più usato per ottenerli e rinnovarli in automatico su Nginx e Apache. Nel 2026 c’è però una novità da non sottovalutare: la durata dei certificati si accorcia. Oggi è di 90 giorni, dal 10 febbraio 2027 scende a 64 e dal 16 febbraio 2028 a 45, quindi il rinnovo automatico non è più una comodità ma una condizione per restare online. Questa guida copre installazione, primo certificato, verifica, rinnovo e certificati wildcard.

Versioni di riferimento: Certbot 5.9.0 (snap, raccomandato da EFF) e Certbot 4.0.0 (pacchetti di Ubuntu 26.04 e Debian 13), Ubuntu 26.04 LTS, Nginx e Apache dai repository. Procedura verificata sulla documentazione ufficiale al 4 novembre 2026.

Cosa cambia con i certificati più brevi

Il profilo tlsserver, facoltativo, emette già certificati da 45 giorni dal 13 maggio 2026. Let’s Encrypt avverte che un rinnovo a intervallo fisso di 60 giorni non basterà più e che va rinnovato a circa due terzi della durata. Certbot si comporta già così: dalla versione 4.0.0 considera un certificato da rinnovare quando ne resta meno di un terzo di validità (prima la soglia era fissa a 30 giorni). Altro dettaglio: dal 4 giugno 2025 Let’s Encrypt non invia più email di avviso prima della scadenza, quindi non contate su un promemoria.

Prerequisiti

• Il sito risponde in HTTP con il nome di dominio corretto. Con Nginx la direttiva server_name deve contenere esattamente i nomi del certificato; con Apache ServerName e ServerAlias. Le guide https://hardwarfare.it/ai-software/linux/installare-nginx-php-fpm-mariadb-ubuntu-lemp/ e https://hardwarfare.it/ai-software/linux/installare-lamp-apache-php-mariadb-ubuntu/ preparano questa base.
• La porta 80 è aperta: la verifica HTTP-01 funziona solo sulla porta 80, lo dice lo standard ACME. Con UFW: sudo ufw allow 'Nginx Full' oppure sudo ufw allow 'Apache Full'. Controllate anche il firewall nel pannello del provider.
• Per un server a casa: serve un IP pubblico e il port forwarding delle porte 80 e 443 sul router. Se il vostro operatore vi mette dietro CGNAT, la porta 80 non è raggiungibile e vi serve la verifica DNS (sezione wildcard) oppure una delle alternative descritte in https://hardwarfare.it/guide-tecniche/guide-reti/cgnat-ip-pubblico-ddns-tailscale-cloudflare/.

Passo 1: installare Certbot

Opzione A: snap (raccomandata da EFF)

EFF, che sviluppa Certbot, raccomanda lo snap perché si aggiorna da solo e include il rinnovo automatico preconfigurato. Se avete già una versione da apt, toglietela prima per non avere due copie:

sudo apt-get remove certbot
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot

Ubuntu Server include snapd; su Debian 13 va installato prima con sudo apt install snapd.

Opzione B: pacchetti della distribuzione

Ubuntu 26.04 e Debian 13 distribuiscono Certbot 4.0.0 con i plugin per Nginx e Apache e un timer systemd già attivo. È più vecchio dello snap, ma include già la nuova soglia di rinnovo:

sudo apt install certbot python3-certbot-nginx

Per Apache il plugin è python3-certbot-apache. Scegliete una sola delle due opzioni.

Passo 2: ottenere il primo certificato

Con Nginx:

sudo certbot --nginx -d TUO_DOMINIO -d www.TUO_DOMINIO

Con Apache:

sudo certbot --apache -d TUO_DOMINIO -d www.TUO_DOMINIO

Al primo avvio Certbot chiede un indirizzo email e l’accettazione dei termini di servizio di Let’s Encrypt, che dovete leggere e confermare voi. Poi verifica il dominio, salva il certificato in /etc/letsencrypt/live/TUO_DOMINIO/ e modifica la configurazione del sito per usarlo. In questa modalità attiva per impostazione predefinita anche il reindirizzamento da HTTP a HTTPS (si disattiva con --no-redirect). Se preferite modificare a mano la configurazione, usate certonly al posto dell’installazione automatica: sudo certbot certonly --nginx -d TUO_DOMINIO.

openssl s_client -connect TUO_DOMINIO:443 -servername TUO_DOMINIO -brief < /dev/null
openssl s_client -connect TUO_DOMINIO:443 -servername TUO_DOMINIO < /dev/null 2>/dev/null | openssl x509 -noout -issuer -dates

Passo 3: controllare il rinnovo automatico

Il rinnovo lo esegue certbot renew, che si può lanciare quante volte si vuole: agisce solo sui certificati vicini alla scadenza. La prova generale usa l’ambiente di staging di Let’s Encrypt e non tocca i certificati veri:

sudo certbot renew --dry-run
systemctl list-timers

Se ottenete i certificati con certonly, il web server non viene ricaricato da solo dopo il rinnovo e continuerebbe a usare il certificato vecchio. Il metodo più robusto è uno script nella cartella /etc/letsencrypt/renewal-hooks/deploy/: Certbot esegue i file eseguibili che trova lì dopo ogni rinnovo riuscito.

sudo nano /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

#!/bin/sh
systemctl reload nginx

sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
sudo certbot renew --dry-run --run-deploy-hooks

Con --run-deploy-hooks la simulazione esegue anche gli hook, così vedete subito se lo script funziona. Con Apache sostituite nginx con apache2. Chi vuole provare in anticipo i certificati da 45 giorni può aggiungere --preferred-profile tlsserver: se il profilo un giorno non esistesse più, Certbot torna al predefinito senza far fallire il rinnovo.

Passo 4: certificato wildcard con Cloudflare (verifica DNS-01)

Un certificato *.TUO_DOMINIO copre tutti i sottodomini di primo livello, ma richiede la verifica DNS-01: Certbot crea un record TXT tramite le API del DNS e Let’s Encrypt lo controlla. È anche la soluzione quando la porta 80 non è raggiungibile.

Prima create in Cloudflare un API Token (non la Global API Key, che dà accesso a tutto l’account) con permesso Zone:DNS:Edit limitato alla zona del vostro dominio. Poi installate il plugin. Con lo snap:

sudo snap set certbot trust-plugin-with-root=ok
sudo snap install certbot-dns-cloudflare

Con apt: sudo apt install python3-certbot-dns-cloudflare. Salvate il token in un file leggibile solo da root:

sudo mkdir -p /root/.secrets/certbot
sudo nano /root/.secrets/certbot/cloudflare.ini
sudo chmod 600 /root/.secrets/certbot/cloudflare.ini

Contenuto del file:

dns_cloudflare_api_token = TUO_TOKEN_CLOUDFLARE

sudo certbot certonly --dns-cloudflare --dns-cloudflare-credentials /root/.secrets/certbot/cloudflare.ini -d TUO_DOMINIO -d '*.TUO_DOMINIO'

Il ricaricamento di Nginx dopo i rinnovi lo fa lo script in renewal-hooks/deploy creato al passo 3. Gli apici attorno a *.TUO_DOMINIO evitano che la shell interpreti l’asterisco. Se la verifica fallisce perché il record non si è ancora propagato, aggiungete --dns-cloudflare-propagation-seconds 60 (il valore predefinito è 10 secondi). Il certificato finisce in /etc/letsencrypt/live/TUO_DOMINIO/; per usarlo in Nginx, nel blocco server con listen 443 ssl; indicate:

ssl_certificate /etc/letsencrypt/live/TUO_DOMINIO/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/TUO_DOMINIO/privkey.pem;

In alternativa, sudo certbot install --cert-name TUO_DOMINIO --nginx applica il certificato alla configurazione esistente.

Se qualcosa va storto

Quando la verifica non riesce, Certbot stampa Certbot failed to authenticate some domains seguito da The Certificate Authority reported these problems: e dal motivo. I casi più comuni:

• Timeout during connect (likely firewall problem): Let’s Encrypt non raggiunge la porta 80. Controllate UFW, il firewall del provider e, per i server di casa, il port forwarding sul router. Se siete dietro CGNAT, non c’è regola da aprire: usate la verifica DNS.
• Connection refused: la porta è raggiungibile ma nessun servizio ascolta. Il web server è spento oppure ascolta solo su IPv4 mentre il dominio ha un record AAAA che punta a un indirizzo IPv6 non configurato.
• Invalid response from seguito da un codice 404: la richiesta arriva, ma a un altro sito o a un’altra cartella. Di solito il server_name non corrisponde al dominio, oppure una regola blocca /.well-known/acme-challenge/.
• Dominio dietro il proxy di Cloudflare (nuvola arancione): la verifica HTTP-01 passa attraverso Cloudflare. Let’s Encrypt segue i reindirizzamenti, ma regole di sicurezza o di redirect sulla zona possono interferire. Se non volete toccarle, la verifica DNS-01 con il plugin è la strada più pulita.
• Limiti di rilascio: al massimo 5 certificati per lo stesso insieme esatto di nomi ogni 7 giorni e 50 per dominio registrato ogni 7 giorni. Per le prove usate sempre --dry-run, che lavora sull’ambiente di staging.
• Unsafe permissions on credentials configuration file: il file del token Cloudflare è leggibile da altri utenti. Correggete con sudo chmod 600.

Come tornare indietro

Prima di cancellare un certificato vanno tolti i riferimenti nella configurazione del web server, altrimenti Nginx o Apache non ripartono. La documentazione di Certbot suggerisce di cercarli con sudo bash -c 'grep -R live/TUO_DOMINIO /etc/{nginx,httpd,apache2}', rimuovere le righe trovate (o puntarle temporaneamente a un certificato autofirmato, come propone la documentazione), verificare con sudo nginx -t (o sudo apachectl configtest) e solo allora eliminare il certificato con sudo certbot delete --cert-name TUO_DOMINIO. Se la chiave privata è stata compromessa, il comando giusto è certbot revoke.

L’alternativa: Caddy

Se state partendo da zero, valutate Caddy: per impostazione predefinita serve tutti i siti in HTTPS, ottiene e rinnova i certificati da solo e reindirizza automaticamente HTTP verso HTTPS. Un reverse proxy completo verso un servizio in ascolto su 127.0.0.1:8080 si scrive in tre righe di Caddyfile:

TUO_DOMINIO {
    reverse_proxy 127.0.0.1:8080
}

La nostra lettura

Ottenere il certificato richiede un minuto; quello che conta è sapere che il rinnovo funziona. Con le durate che scendono a 64 giorni nel 2027 e a 45 nel 2028, il dry run periodico e un controllo esterno delle scadenze diventano manutenzione ordinaria, non più un’eccezione. Chi installa WordPress trova il passo successivo in https://hardwarfare.it/ai-software/linux/installare-wordpress-vps-nginx-wp-cli/.

Articolo redatto con il supporto di strumenti di intelligenza artificiale e verificato dalla redazione. Come usiamo l'AI · Come lavoriamo