Cosa significa “La connessione non è privata” e come risolverlo

Cosa significa l’errore

Il browser si è collegato, il server ha presentato il suo certificato e il browser si è rifiutato di fidarsi. Chrome mostra “La connessione non è privata” con un codice di errore (le versioni precedenti dicevano “La tua connessione non è privata”); Firefox dice “Avviso: potenziale rischio per la sicurezza”; Safari “Questa connessione non è privata”. Il sito non è stato violato e il tuo dispositivo non è infetto: il certificato inviato dal server non supera i controlli del browser.

Il codice di errore dice quale controllo è fallito:

• NET::ERR_CERT_DATE_INVALID: il certificato è scaduto o non è ancora valido (oppure l’orologio del visitatore è sbagliato).
• NET::ERR_CERT_COMMON_NAME_INVALID: il certificato vale per un altro nome, per esempio www.example.com ma non example.com.
• NET::ERR_CERT_AUTHORITY_INVALID: nessuna autorità riconosciuta lo garantisce: autofirmato, emittente sconosciuto o certificato intermedio mancante.
• NET::ERR_CERT_REVOKED: l’emittente ha revocato il certificato.
• SSL_ERROR_BAD_CERT_DOMAIN e SEC_ERROR_EXPIRED_CERTIFICATE: le varianti di Firefox per nome e data.

Cause frequenti

1. Il certificato è scaduto. I certificati Let’s Encrypt durano 90 giorni; il rinnovo automatico falliva da settimane e nessuno se n’è accorto fino al giorno della scadenza. I certificati a pagamento scadono dopo un anno, e il promemoria è arrivato a un vecchio indirizzo e-mail.
2. Rinnovato, ma senza ricaricare. certbot ha scritto il nuovo certificato sul disco, ma il server web continua a servire il vecchio perché manca l’hook di ricarica.
3. Nome sbagliato. Il certificato copre example.com, ma i visitatori arrivano da www.example.com, oppure un sottodominio nuovo è stato aggiunto senza certificato.
4. Manca il certificato intermedio. Il server invia solo il proprio certificato, non la catena. I browser desktop spesso colmano il vuoto dalla cache; telefoni e app falliscono.
5. Un problema di orologio. Sul computer del visitatore, una data sbagliata fa sembrare tutti i certificati scaduti o non ancora validi. Sul server, un orologio sbagliato rompe il rinnovo.
6. Un CDN o un proxy davanti, con un proprio certificato scaduto o senza il nome giusto, mentre il server di origine è a posto.

Se sei un visitatore

Controlla prima data e ora del dispositivo; una batteria CMOS esaurita o la sincronizzazione dell’ora disattivata fanno fallire tutti i siti. Poi prova da un’altra rete. Se l’avviso compare solo su un sito, da qualsiasi dispositivo, il problema è il certificato del sito: deve correggerlo il proprietario. Cliccare su “Procedi su … (non sicuro)” va bene per un sito che conosci, mai per uno con password o pagamenti.

Se è il tuo sito: verificare prima

Apri l’SSL checker: data di scadenza, nomi coperti e catena completa o no, dall’esterno e senza cache del browser. Poi sul tuo server:

# cosa invia il server?
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject -ext subjectAltName

# cosa c’è sul disco?
sudo certbot certificates

# l’orologio è giusto?
timedatectl

Date più recenti sul disco che nella risposta del server? Sei nel caso 2: rinnovato, ma senza ricaricare.

Soluzioni sul tuo server

1. Rinnovare con certbot

sudo certbot renew
# se renew risponde "not yet due" mentre il server serve un certificato vecchio:
sudo certbot renew --force-renewal
sudo systemctl reload nginx     # oppure apache2

Se il rinnovo fallisce, il motivo è nell’output. I classici: la porta 80 è bloccata o reindirizzata dove certbot non se lo aspetta (la sfida HTTP-01 deve arrivare a /.well-known/acme-challenge/ in HTTP semplice), il DNS punta altrove, oppure scatta un limite dopo troppi tentativi falliti. Correggi la causa e lancia sudo certbot renew --dry-run finché non passa.

2. Automatizzare la ricarica

# Debian/Ubuntu: certbot installa un timer; controllalo
systemctl list-timers | grep certbot

# hook perché il server web prenda il nuovo certificato
printf '#!/bin/sh\nsystemctl reload nginx\n' | sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-web.sh
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-web.sh

3. Includere il nome mancante

sudo certbot --nginx -d example.com -d www.example.com -d shop.example.com --expand

--expand sostituisce il certificato esistente con uno che copre tutti i nomi indicati.

4. Riparare la catena

Con certbot, il server web deve puntare a fullchain.pem, mai a cert.pem:

ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Apache: SSLCertificateFile con fullchain.pem. Per un certificato acquistato, scarica il certificato intermedio (“CA bundle”) dall’emittente e accodalo al file del certificato. Prova con sudo nginx -t (Apache: sudo apachectl configtest), ricarica e verifica la catena con l’SSL checker.

5. Mettere a posto l’orologio

sudo timedatectl set-ntp true
timedatectl

Un orologio che sbaglia di più di qualche minuto fa fallire la verifica dei certificati in entrambe le direzioni.

6. Hosting condiviso o site builder

La maggior parte dei provider di hosting emette e rinnova i certificati Let’s Encrypt dal pannello cliente (“SSL/TLS”, “Sicurezza”, “Let’s Encrypt”). Aprilo, controlla che il certificato copra sia example.com sia www.example.com, e clicca su rinnova o riemetti. Se il pannello mostra un certificato valido mentre i browser dicono il contrario, il problema di ricarica o di catena è presso il provider di hosting.

Se il problema è presso il tuo provider di hosting

Buongiorno, da circa le 6:00 (UTC) i browser mostrano “La connessione non è privata” (NET::ERR_CERT_DATE_INVALID) sul mio sito example.com. Il pannello cliente mostra un certificato valido, quindi il server sembra servire ancora quello vecchio. Potete ricaricare il certificato sul server e verificare il rinnovo automatico per il mio dominio?

Perché non succeda di nuovo

Un certificato scaduto è l’unico guasto con una data nota in anticipo. Il monitoraggio dei certificati SSL ti avvisa prima della scadenza, e di nuovo se la catena o il nome non sono corretti; 5 controlli sono gratis. Il browser non arriva nemmeno a leggere il certificato e mostra ERR_SSL_PROTOCOL_ERROR? È un altro caso: la connessione sicura fallisce prima del certificato. E se il server rifiuta direttamente la connessione sulla porta 443? Allora è un ERR_CONNECTION_REFUSED.

Down? Interveniamo. Sul tuo server o su un hosting condiviso con accesso SSH, il Quick Fix rinnova il certificato dove certbot è configurato e ricarica il server web, a prezzo fisso, 24 ore su 24, anche nel fine settimana; il Deep Fix mette in piedi il rinnovo dove manca, a blocchi di 15 minuti; la stima è il prezzo massimo.