Certificato scaduto o non valido: leggere l'errore e rimetterlo a posto

La verifica più veloce, prima di leggere il resto

Sito giù, errore di certificato in homepage. Prima cosa da lanciare, da un terminale qualsiasi (non serve essere sul server):

openssl s_client -connect tuodominio.it:443 -servername tuodominio.it -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Questo comando si connette alla porta 443 come farebbe un browser e stampa a chi è intestato il certificato, chi lo ha firmato e le date di validità (notBefore/notAfter). È il certificato che il server sta davvero servendo in quel momento, non quello che pensi di aver installato: se hai rinnovato ieri ma qui vedi ancora la data vecchia, il problema non è il certificato, è che Nginx o Apache non lo ha ricaricato.

I quattro messaggi del browser, e cosa significano

Messaggio tipico nel browser	Cosa sta dicendo	Causa più frequente
NET::ERR_CERT_DATE_INVALID / "Il certificato è scaduto"	La data di oggi è fuori dall'intervallo notBefore/notAfter del certificato	Rinnovo automatico non partito o fallito
NET::ERR_CERT_COMMON_NAME_INVALID / "Il nome non corrisponde"	Il dominio nella barra indirizzi non è tra quelli elencati nel certificato (Subject Alternative Name)	Certificato richiesto per un altro dominio/sottodominio, o manca il www
"Catena di certificati incompleta" / avviso solo su alcuni dispositivi	Il server non invia il certificato intermedio, solo quello finale	Configurazione del server che serve solo il cert.pem senza la fullchain
NET::ERR_CERT_AUTHORITY_INVALID / "Autorità non riconosciuta"	Il certificato è firmato da una CA che il dispositivo non ha tra le radici fidate	Certificato self-signed, CA scaduta (vedi il caso IdenTrust/Let's Encrypt), o root store vecchio sul client

Per chi non è sistemista: il browser sta solo controllando tre cose, in ordine — il certificato non è scaduto, è intestato al sito giusto, ed è firmato da qualcuno di cui il tuo computer si fida fino in fondo alla catena. Quando una di queste tre non torna, blocca la pagina.

Causa 1: certificato scaduto

Come si capisce se è la tua. Guarda l'output del comando sopra: la riga notAfter= deve riportare una data futura. Se è nel passato, è questa.

Come si risolve (Ubuntu 24.04, Nginx, Certbot).

sudo certbot certificates

Elenca i certificati gestiti da Certbot con relativa scadenza. Se quello del dominio in errore è scaduto o vicino a scadere, forza il rinnovo:

sudo certbot renew --cert-name tuodominio.it --force-renewal
sudo systemctl reload nginx

Il secondo comando è quello che spesso manca: Certbot rinnova il file su disco ma non riavvia da solo il servizio web, a meno che tu abbia impostato un deploy-hook.

Su cPanel. Nella sezione SSL/TLS Status di WHM/cPanel puoi vedere la scadenza per ogni dominio e forzare "Run AutoSSL" sul dominio interessato.

Su Plesk. In "Siti web e domini" → dominio → "Certificati SSL/TLS" si vede la data di scadenza e c'è il pulsante per rinnovare manualmente.

Causa 2: nome non corrispondente

Come si capisce. Nello stesso output di openssl, cerca la riga subject= e, se vuoi vedere tutti i nomi coperti, usa:

openssl x509 -in /etc/letsencrypt/live/tuodominio.it/cert.pem -noout -text | grep -A1 "Subject Alternative Name"

Se il dominio che stai visitando (es. www.tuodominio.it) non compare in quella lista, è questa la causa.

Come si risolve. Rifai la richiesta includendo tutti i nomi che ti servono:

sudo certbot certonly --nginx -d tuodominio.it -d www.tuodominio.it

Certbot sovrascrive il certificato esistente con uno nuovo che copre entrambi i nomi.

Causa 3: catena di certificati incompleta

Questo è l'errore più subdolo perché su Chrome da desktop spesso non si vede (il browser ha una cache delle intermedie), ma fallisce su smartphone, su client API, curl, o su scanner SSL esterni.

Come si capisce se è la tua. Nell'output di openssl s_client -showcerts conta quanti blocchi BEGIN CERTIFICATE vedi. Se ne vedi uno solo, il server sta mandando solo il certificato finale senza l'intermedio. Deve sempre essere servita la fullchain, non il cert da solo.

Come si risolve (Nginx). Nel blocco server controlla che la direttiva punti al file fullchain, non al cert singolo:

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

Con Certbot, fullchain.pem contiene già certificato più intermedio: se nella configurazione compare cert.pem invece di fullchain.pem, è questo l'errore. Dopo la correzione:

sudo nginx -t && sudo systemctl reload nginx

Su Apache. La direttiva da controllare è SSLCertificateFile, che deve puntare anch'essa a fullchain.pem; dalla versione 2.4.8 Apache non richiede più una direttiva separata per la catena.

Causa 4: autorità non riconosciuta

Come si capisce. Nell'output di openssl, la riga issuer= mostra chi ha firmato il certificato. Se è un nome che non riconosci (una CA interna, un proxy aziendale) o se il certificato è self-signed (subject e issuer coincidono), il dispositivo del visitatore non ha motivo di fidarsi.

Come si risolve. Se è un certificato self-signed lasciato per sbaglio in produzione, va sostituito con uno emesso da una CA pubblica: stesso comando di Causa 1, certbot certonly --nginx -d tuodominio.it. Se invece il certificato è corretto ma l'errore compare solo su dispositivi vecchi, è un problema di root store del client, non del server: qui non c'è nulla da sistemare lato hosting, va segnalato all'utente.

Il caso "ho rinnovato ma il browser vede ancora il vecchio"

Succede quasi sempre per uno di questi tre motivi, in ordine di frequenza:

1. Il servizio web non è stato ricaricato. Certbot scrive il nuovo file in /etc/letsencrypt/live/tuodominio.it/, ma Nginx/Apache tengono il certificato vecchio in memoria finché non vengono ricaricati. Verifica con sudo systemctl status nginx che non ci siano errori, poi sudo systemctl reload nginx.
2. Un reverse proxy o un CDN davanti al server (es. Cloudflare, un load balancer) sta ancora servendo la cache del certificato precedente. In questo caso il problema non è sul tuo server: va svuotata la cache lato proxy o atteso il TTL.
3. Un virtual host sbagliato. Il dominio in errore è servito da un blocco server diverso da quello che hai aggiornato (capita con più siti sulla stessa macchina). Verifica con sudo nginx -T | grep -A5 server_name quale blocco risponde per quel nome.

Come automatizzare il rinnovo e non ritrovarsi qui tra 90 giorni

Let's Encrypt emette certificati con validità breve, per questo serve il rinnovo automatico. Certbot include un cron job o un systemd timer che rinnova i certificati automaticamente prima della scadenza, quindi di norma non c'è bisogno di rilanciare il comando manualmente. Per verificare che il meccanismo funzioni davvero, senza intaccare il certificato in produzione:

sudo certbot renew --dry-run

Su Ubuntu con systemd, il timer è gestito automaticamente dal pacchetto; per controllare se è attivo:

systemctl list-timers | grep certbot

Se il sistema usa ancora cron invece di systemd, il job si trova in /etc/cron.d/certbot; da documentazione, questo cronjob NON viene eseguito se è in uso systemd come sistema di init: in quel caso ha la precedenza il timer.

Se il problema è del fornitore, non tuo

Se il dominio è su hosting condiviso con pannello (cPanel con AutoSSL, Plesk con Let's Encrypt integrato) e il certificato non si rinnova nonostante tutto sembri corretto lato DNS, il problema può essere lato provider: blocco della porta 80 per la validazione HTTP, limite di rate dell'account, o un bug del pannello dopo un aggiornamento. In questo caso, apri un ticket all'assistenza allegando:

• l'output completo di openssl s_client -connect tuodominio.it:443 -servername tuodominio.it -showcerts;
• l'output di sudo certbot certificates (o lo screenshot della sezione SSL del pannello);
• l'orario esatto in cui hai tentato il rinnovo, per far incrociare i log al tecnico.

Senza questi tre elementi, il primo livello di assistenza perde tempo a richiederteli, e il sito resta giù più a lungo.