«La connessione non è privata» significa che il browser non è riuscito a verificare il certificato SSL del sito e ha interrotto la connessione prima di caricare la pagina. Il codice sotto il messaggio indica il motivo: NET::ERR_CERT_DATE_INVALID (il certificato è scaduto oppure l’orologio del dispositivo è sbagliato), NET::ERR_CERT_COMMON_NAME_INVALID (il certificato è stato emesso per un altro nome, spesso senza www), NET::ERR_CERT_AUTHORITY_INVALID (certificato autofirmato o certificato intermedio mancante). Il visitatore può sistemare solo l’orologio e la rete; tutto il resto spetta al proprietario del sito.
Come abbiamo testato
Il 10 novembre 2026 su un banco di prova: container Ubuntu 24.04.5, nginx 1.24.0, OpenSSL 3.0.13, curl, Chromium 153 (il browser completo in modalità headless tramite Playwright). Abbiamo creato una nostra CA radice di test, un intermedio e diversi certificati server, avviato su porte separate siti con un certificato scaduto, uno autofirmato, uno senza www e uno senza la catena intermedia, e spostato l’orologio del client con libfaketime. Per ogni caso abbiamo annotato il codice di errore di Chromium, il testo dell’avviso in inglese, ucraino e russo e l’output di curl e openssl. Si tratta del comportamento del banco di prova, non di dati dei server RichHost. Le date tratte da fonti ufficiali sono state verificate lo stesso giorno.
Cosa mostra il browser e dove trovare il codice di errore
In Chromium 153 con l’interfaccia in italiano la pagina di avviso si intitola «La connessione non è privata». Non conta il titolo, ma la piccola riga sotto: NET::ERR_CERT_ seguito dal motivo. Il pulsante «Avanzate» apre una spiegazione in linguaggio semplice e, se il browser lo consente, un link del tipo «Procedi su … (non sicuro)».
Ecco, in sintesi, cosa ha scritto Chromium (interfaccia inglese) sotto «Avanzate» per ciascuna causa sul nostro banco:
- certificato scaduto: il certificato di sicurezza è scaduto 73 giorni fa, con la data dell’orologio del computer e la domanda se sia corretta;
- certificato senza www: il certificato di sicurezza proviene da mysite.test (avevamo aperto www.mysite.test);
- certificato autofirmato e certificato senza catena intermedia: il certificato di sicurezza non è considerato attendibile dal sistema operativo del computer. Stesso testo, cause diverse.
Tabella: codice di errore, causa e chi lo risolve
| Codice di errore | Causa | Chi lo risolve | Come |
|---|---|---|---|
| NET::ERR_CERT_DATE_INVALID, scaduto da N giorni | Certificato scaduto, il rinnovo automatico non è andato a buon fine | Proprietario | Rinnovare il certificato, controllare il rinnovo automatico e il ricaricamento del server web |
| NET::ERR_CERT_DATE_INVALID con una pagina che segnala l’orologio indietro | Data o ora sbagliata sul dispositivo del visitatore | Visitatore | Attivare data e ora automatiche, ricaricare la pagina |
| NET::ERR_CERT_COMMON_NAME_INVALID | Il certificato non include il nome aperto: www, un sottodominio, un altro dominio sullo stesso IP | Proprietario | Riemettere il certificato con tutti i nomi, www compreso |
| NET::ERR_CERT_AUTHORITY_INVALID su un solo sito | Certificato autofirmato oppure il server non invia l’intermedio | Proprietario | Installare un certificato di una CA pubblica (Let’s Encrypt), servire la catena completa |
| NET::ERR_CERT_AUTHORITY_INVALID su molti siti contemporaneamente | Qualcosa tra te e il sito intercetta il traffico: la pagina di accesso di un Wi-Fi pubblico, la scansione HTTPS di un antivirus, un proxy aziendale | Visitatore | Provare un’altra rete, accedere al Wi-Fi, disattivare la scansione HTTPS dell’antivirus |
| Nessun link per procedere, viene citato HSTS | Una qualsiasi delle cause sopra su un sito con HSTS | Proprietario | Sistemare il certificato: i visitatori non possono aggirare questo avviso |
| Nessun avviso, la pagina si apre ma il lucchetto è incompleto o qualcosa non funziona | Contenuti misti, un altro problema | Proprietario | Sostituire gli indirizzi http:// con https:// nel codice e nel database |
Cosa fare se sei un visitatore
- Controlla la data che compare dopo aver cliccato su «Avanzate». Se è sbagliata, il problema è il tuo dispositivo: correggi l’orologio e ricarica la pagina.
- Apri lo stesso sito con la rete mobile invece del Wi-Fi. Se l’errore sparisce, la causa è la rete: in un bar o in un hotel apri prima un qualsiasi sito senza HTTPS, così compare la pagina di accesso.
- Se l’avviso compare su tutti i siti, controlla l’antivirus e le estensioni del browser che «analizzano HTTPS».
- Se fallisce un solo sito con DATE_INVALID, COMMON_NAME_INVALID o AUTHORITY_INVALID, può risolvere solo il proprietario. Mandagli il codice di errore e l’indirizzo esatto.
Non inserire password o dati della carta in una pagina raggiunta tramite «Procedi su … (non sicuro)». In quel momento il browser non può dimostrare che stai comunicando con il sito vero.
Certificato scaduto: ERR_CERT_DATE_INVALID
Una causa tipica lato proprietario. Sul banco il server inviava un certificato scaduto il 30 agosto 2026. Chromium mostrava NET::ERR_CERT_DATE_INVALID, mentre curl e openssl indicavano direttamente il motivo:
$ curl https://mysite.test:11102/ curl: (60) SSL certificate problem: certificate has expired $ openssl s_client -connect mysite.test:11102 -servername mysite.test verify error:num=10:certificate has expired
Un solo comando mostra la data di scadenza e i nomi nel certificato di qualsiasi sito:
$ echo | openssl s_client -connect mysite.test:443 -servername mysite.test 2>/dev/null \
| openssl x509 -noout -subject -issuer -enddate -ext subjectAltName
subject=CN = mysite.test
issuer=CN = CW11 Test Intermediate R1
notAfter=Aug 30 10:00:00 2026 GMT
X509v3 Subject Alternative Name:
DNS:mysite.test, DNS:www.mysite.test
Per il monitoraggio usa openssl x509 -noout -checkend 2592000: restituisce un errore se il certificato scade entro 30 giorni. Non contare sulle email della CA: Let’s Encrypt ha smesso di inviare promemoria di scadenza il 4 giugno 2025 (annuncio di Let’s Encrypt). Inoltre i certificati diventano più brevi per tutti: in base alla votazione SC-081 del CA/Browser Forum, la durata massima di un certificato pubblico è di 200 giorni dal 15 marzo 2026, di 100 giorni dal 15 marzo 2027 e di 47 giorni dal 15 marzo 2029 (calendario di DigiCert, verificato il 10.11.2026). Senza rinnovo automatico i certificati scaduti diventeranno la norma, quindi configura sul tuo hosting un certificato Let’s Encrypt gratuito che si rinnova da solo. Con RichHost un certificato SSL gratuito Let’s Encrypt è incluso in ogni piano di hosting.
Orologio sbagliato sul dispositivo del visitatore
Un certificato è valido in un intervallo di tempo, e il browser lo confronta con l’orologio del dispositivo, non con quello del server. Abbiamo lasciato sul server un certificato valido (dal 10 novembre 2026 all’8 febbraio 2027) e spostato l’ora solo sul client:
| Data sul client | curl | Chromium 153 |
|---|---|---|
| 1 marzo 2027 | certificate has expired | ERR_CERT_DATE_INVALID, scaduto da 21 giorni, link per procedere presente |
| 1 ottobre 2026 | certificate is not yet valid | ERR_CERT_DATE_INVALID, certificato che sarebbe valido solo tra 40 giorni |
| 15 gennaio 2024 | certificate is not yet valid | Una pagina a parte che segnala l’orologio indietro, con un pulsante per aggiornare data e ora, nessun modo di procedere |
Consiglio per i proprietari: se un solo visitatore si lamenta mentre il sito funziona per te e per gli altri, chiedigli il testo sotto «Avanzate». La data che contiene mostra subito quale orologio è sbagliato.
Con o senza www: ERR_CERT_COMMON_NAME_INVALID
Un certificato elenca i nomi per cui è valido. Sul banco il certificato conteneva solo mysite.test: il dominio senza www funzionava, www.mysite.test no:
$ curl https://www.mysite.test:11103/ curl: (60) SSL: no alternative certificate subject name matches target host name 'www.mysite.test' $ openssl s_client -connect www.mysite.test:11103 -servername www.mysite.test -verify_hostname www.mysite.test verify error:num=62:hostname mismatch
Punto chiave: un redirect da www al dominio senza www qui non serve. Il browser verifica il certificato mentre stabilisce la connessione, prima di ricevere qualsiasi risposta dal server, compreso un 301. Il certificato deve quindi includere entrambi i nomi, e solo dopo si reindirizza l’uno sull’altro. Le regole di redirect sono nella nostra guida con esempi di file .htaccess, e se il redirect finisce in un ciclo leggi come risolvere ERR_TOO_MANY_REDIRECTS. Lo stesso errore compare quando più siti condividono un IP e il server invia il certificato di un altro dominio: di solito l’SSL non è semplicemente attivato per il tuo dominio nel pannello di controllo.
Certificato autofirmato: ERR_CERT_AUTHORITY_INVALID
Nessuno garantisce per un certificato autofirmato, quindi il browser non ha motivo di fidarsi. Sul banco curl ha restituito (60) SSL certificate problem: self-signed certificate, openssl ha dato verify error:num=18:self-signed certificate e Chromium ha mostrato NET::ERR_CERT_AUTHORITY_INVALID. Un certificato del genere resta spesso dopo l’installazione di un server o di un pannello, quando il sito è già online ma un certificato vero non è mai stato emesso. La soluzione: un certificato Let’s Encrypt gratuito oppure uno a pagamento di una CA commerciale. Le differenze e quando conviene pagare sono spiegate nel nostro articolo sul costo di un certificato SSL.
Intermedio mancante: funziona nel browser, fallisce in curl
Il caso più insidioso. Il sito invia solo il proprio certificato, senza l’intermedio che lo collega alla CA radice. Abbiamo costruito due versioni di un server del genere:
- certificato con l’indirizzo dell’intermedio nel campo AIA (come fanno le CA pubbliche): Chromium ha scaricato da sé l’intermedio e ha aperto la pagina con stato 200, mentre curl e openssl hanno fallito;
- certificato senza campo AIA: anche Chromium ha mostrato NET::ERR_CERT_AUTHORITY_INVALID.
$ curl https://mysite.test:11106/ curl: (60) SSL certificate problem: unable to get local issuer certificate $ openssl s_client -connect mysite.test:11106 -servername mysite.test verify error:num=20:unable to get local issuer certificate Verify return code: 21 (unable to verify the first certificate)
Ecco perché i proprietari vedono un lucchetto nel proprio browser e non credono alle segnalazioni, mentre moduli di pagamento, job cron, client API e alcune app ricevono un errore. Conta i certificati inviati dal server:
$ echo | openssl s_client -connect mysite.test:443 -servername mysite.test -showcerts 2>/dev/null | grep -c 'BEGIN CERTIFICATE' 1
Il server configurato correttamente sul banco ne inviava 2 (il proprio e l’intermedio). La soluzione: in nginx ssl_certificate deve puntare al file fullchain (prima il certificato del sito, poi l’intermedio); in un pannello di controllo incolla l’intermedio nel campo apposito del modulo SSL. L’ordine conta: quando abbiamo messo l’intermedio per primo, nginx -t si è rifiutato di partire con key values mismatch.
HSTS: perché manca il link per procedere
L’intestazione Strict-Transport-Security dice al browser che un sito funziona solo in HTTPS. Sul banco abbiamo prima aperto un sito che inviava Strict-Transport-Security: max-age=31536000 con un certificato valido, poi lo stesso dominio con uno scaduto. Chromium ha mostrato NET::ERR_CERT_DATE_INVALID, ma il pulsante per tornare al sicuro è stato sostituito da «Ricarica», il link per procedere è sparito e la spiegazione diceva che il sito non poteva essere visitato in quel momento perché usa HSTS. Un dominio di controllo senza l’intestazione, nelle stesse condizioni, ha mantenuto il link per procedere. Da quel momento il browser riscriveva anche da solo gli indirizzi http:// in https://.
Per i visitatori questo avviso non si può aggirare, ed è voluto. Per i proprietari: attiva HSTS solo dopo aver verificato il rinnovo automatico, perché qualsiasi problema di certificato bloccherà tutti quelli che hanno già visitato il sito.
Contenuti misti: un altro problema spesso confuso con questo
Se una pagina HTTPS carica script o immagini da indirizzi http://, non compare alcun avviso a tutta pagina: la pagina si apre e il problema è visibile solo nella console per sviluppatori (F12). Sul banco Chromium ha bloccato lo script e ha convertito automaticamente l’indirizzo dell’immagine in https:
Mixed Content: The page at 'https://mysite.test:11101/mixed.html' was loaded over HTTPS, but requested an insecure script 'http://mysite.test:11110/app.js'. This request has been blocked; the content must be served over HTTPS.
Il risultato: un menu, uno slider o un modulo smette di funzionare anche se il certificato è a posto. Scopri come risolvere i contenuti misti dopo il passaggio a HTTPS e leggi la nostra panoramica sul certificato SSL su hosting condiviso.
Checklist per il proprietario
- Apri il sito con e senza www, da computer e da telefono. Annota il codice di errore.
- Esegui il comando con
-enddate -ext subjectAltName: la data è ancora valida, ci sono tutti i nomi? - Conta i certificati con
-showcerts: devono essere almeno 2. - Esegui
curl -I https://your-domain/: curl non scarica gli intermedi mancanti e farà emergere una catena incompleta. - Dopo la correzione aggiungi un controllo con
-checkendal monitoraggio o a cron.
Se il sito non si apre affatto e non compare nessun avviso sul certificato, la causa è altrove, lato server. Nelle tariffe di hosting RichHost un certificato Let’s Encrypt gratuito si attiva nel nostro pannello di controllo proprietario con assistente IA (verifica che copra anche l’indirizzo con www), e il supporto è attivo dalle 10:00 alle 20:00, ora di Kyiv, con una risposta tipica in circa 30 minuti.
Domande frequenti
È sicuro cliccare su «Procedi su … (non sicuro)»?
Solo se conosci la causa esatta, per esempio se è il tuo server di test. Sul sito di qualcun altro non inserire lì password o dati di pagamento: il browser non può confermare che la pagina sia autentica.
Perché il sito funziona per me ma non per il mio cliente?
Spesso per una catena incompleta: sul nostro banco Chromium ha recuperato da solo l’intermedio mancante, curl e openssl no. La seconda causa frequente è un orologio sbagliato sul dispositivo del cliente.
Perché l’errore compare solo sull’indirizzo con www?
Il certificato è stato emesso senza il nome con www. Riemettilo con entrambi i nomi; un redirect 301 non elimina questo errore.
Svuotare la cache del browser aiuta?
No. Il certificato viene verificato a ogni nuova connessione e la cache delle pagine non c’entra. Quando il proprietario ha sistemato il certificato, basta ricaricare la pagina.
