Un errore del certificato SSL significa che il browser non è riuscito a stabilire una connessione sicura di cui si fida, quindi si ferma e mostra un avviso al posto del tuo sito. Le cause più comuni sono un certificato scaduto (NET::ERR_CERT_DATE_INVALID), un certificato che non copre il nome di dominio (ERR_CERT_COMMON_NAME_INVALID), un certificato di cui il browser non si fida (ERR_CERT_AUTHORITY_INVALID) e un server che invia una catena di certificati incompleta o usa impostazioni TLS obsolete. Quasi tutti si risolvono sul server, e il più comune, la scadenza, è del tutto evitabile.
Questa guida passa in rassegna gli errori che i visitatori vedono davvero, che cosa causa ciascuno e come risolverlo, con i comandi da eseguire per controllare il tuo sito.
Perché i browser bloccano la pagina
Quando un browser si connette in HTTPS, il server presenta un certificato. Prima di inviare qualsiasi cosa, il browser verifica tre aspetti: che il certificato rientri nelle sue date di validità, che sia stato emesso esattamente per l’hostname nella barra degli indirizzi e che risalga, tramite la catena, a un’autorità di certificazione di cui il browser si fida. Se un controllo fallisce, il browser mostra un avviso a tutta pagina come «La connessione non è privata». A quel punto la maggior parte dei visitatori se ne va. I client API e le app non mostrano alcun avviso: rifiutano la connessione e la tua integrazione smette di funzionare.
I browser chiamano gli stessi problemi in modi diversi. Ecco come si corrispondono gli errori più comuni:
ProblemaChrome ed EdgeFirefoxScaduto o non ancora validoNET::ERR_CERT_DATE_INVALIDSEC_ERROR_EXPIRED_CERTIFICATEHostname erratoNET::ERR_CERT_COMMON_NAME_INVALIDSSL_ERROR_BAD_CERT_DOMAINEmittente non attendibile o autofirmatoNET::ERR_CERT_AUTHORITY_INVALIDSEC_ERROR_UNKNOWN_ISSUERProblema di protocollo o di cifraturaERR_SSL_PROTOCOL_ERROR, ERR_SSL_VERSION_OR_CIPHER_MISMATCHSSL_ERROR_NO_CYPHER_OVERLAP
Safari mostra «Questa connessione non è privata» per la maggior parte di questi casi, con i dettagli dietro «Mostra dettagli».
Prima di tutto, guarda tu stesso il certificato
Prima di correggere qualsiasi cosa, verifica che cosa invia davvero il server. Questo comando mostra le date di validità del certificato, il soggetto e gli hostname che copre:
echo | openssl s_client -connect northwind.shop:443 -servername northwind.shop 2>/dev/null \
| openssl x509 -noout -dates -subject -issuer -ext subjectAltName
Il flag -servername è importante. I server che ospitano più siti scelgono il certificato in base al nome richiesto dal client, e senza questo flag potresti vedere quello sbagliato. Per vedere l’intera catena inviata dal server, aggiungi -showcerts al primo comando.
NET::ERR_CERT_DATE_INVALID
Il certificato è fuori dal suo periodo di validità. Quasi sempre significa che è scaduto. Più raramente è sbagliato l’orologio del computer del visitatore, e così un certificato valido sembra scaduto o non ancora valido.
Cause tipiche lato server:
Il rinnovo automatico ha smesso di funzionare dopo un trasloco del server, un cambio di web server o una modifica DNS che ha compromesso la convalida del dominio.
Il certificato è stato rinnovato, ma il web server non è mai stato ricaricato, quindi serve ancora quello vecchio dalla memoria.
Il certificato è stato emesso a mano un anno fa per un sottodominio che tutti hanno dimenticato.
Un load balancer, una CDN o un secondo server ha ancora il vecchio certificato, mentre il server principale ha quello nuovo.
Soluzione: rinnova il certificato, installalo ovunque venga servito e ricarica il servizio. Con Certbot, un dry run ti dice se il rinnovo funziona prima che diventi un problema:
sudo certbot renew –dry-run
sudo systemctl reload nginx
Poi controlla di nuovo il certificato servito con il comando openssl qui sopra. I visitatori non vedono il file su disco, ma il certificato servito.
Se l’errore lo segnala un solo visitatore e il certificato è valido, chiedigli di controllare data e ora sul suo dispositivo.
NET::ERR_CERT_COMMON_NAME_INVALID
Il certificato è valido, ma non per questo hostname. I browser confrontano la barra degli indirizzi con i nomi elencati nel campo Subject Alternative Name del certificato.
Cause comuni:
Il certificato copre northwind.shop ma non www.northwind.shop, o viceversa.
Un certificato wildcard per *.northwind.shop viene usato su shop.eu.northwind.shop. Un wildcard copre un solo livello.
Un nuovo sottodominio è stato puntato su un server che serve un certificato predefinito per un altro sito.
Un record DNS punta al server sbagliato, per esempio un vecchio hosting o una CDN che non ha un certificato per il tuo dominio.
Soluzione: emetti un certificato che elenchi ogni hostname che servi, oppure uno separato per ciascun hostname, e verifica che ogni server block o virtual host usi quello giusto. Se l’hostname non deve essere servito affatto, rimuovi il suo record DNS.
NET::ERR_CERT_AUTHORITY_INVALID
Il browser non si fida di chi ha firmato il certificato. Cause:
Un certificato autofirmato, spesso rimasto dall’ambiente di staging o dall’installazione predefinita di un pannello di controllo.
Un certificato di un’autorità di certificazione privata o interna usato su un sito pubblico.
Una catena incompleta su alcuni client, vedi sotto.
Qualcosa tra il visitatore e il server che intercetta la connessione, come un proxy aziendale o un antivirus. In quel caso l’errore lo vedono solo alcuni visitatori.
Soluzione: sui siti pubblici sostituisci i certificati autofirmati e interni con uno emesso da un’autorità di certificazione pubblicamente attendibile. I certificati gratuiti di Let’s Encrypt e di servizi simili sono riconosciuti da tutti i principali browser.
Catena di certificati incompleta
Il tuo certificato è firmato da un certificato intermedio, a sua volta firmato da una root di cui il browser si fida. Il server deve inviare il tuo certificato e l’intermedio. Se invia solo il tuo certificato, il risultato dipende dal client: alcuni browser desktop recuperano da soli l’intermedio mancante e non mostrano errori, mentre altri browser, le app mobili, curl e i client API falliscono. Ecco perché questo problema si presenta spesso come «a me funziona, ma i webhook del provider di pagamento non arrivano».
curl lo segnala così:
curl: (60) SSL certificate problem: unable to get local issuer certificate
Soluzione: configura il server con il file della catena completa. Con Certbot su nginx significa fullchain.pem, non cert.pem:
ssl_certificate /etc/letsencrypt/live/northwind.shop/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/northwind.shop/privkey.pem;
ERR_SSL_PROTOCOL_ERROR e incompatibilità di cifratura
Questi errori significano che browser e server non sono riusciti ad accordarsi su come comunicare in modo sicuro, prima ancora di qualsiasi controllo del certificato. Tra le cause: un server che offre solo vecchie versioni del protocollo come TLS 1.0 e 1.1, che i browser attuali non accettano più, una porta configurata male che parla HTTP semplice sulla 443, una configurazione TLS compromessa dopo un aggiornamento, oppure un firewall o un proxy che interferisce con l’handshake.
Soluzione: abilita TLS 1.2 e TLS 1.3, usa le impostazioni di cifratura moderne predefinite del tuo web server o di un generatore di configurazioni affidabile, e verifica che la porta 443 serva davvero TLS. Puoi testare una specifica versione del protocollo con openssl:
openssl s_client -connect northwind.shop:443 -servername northwind.shop -tls1_2
Contenuti misti
I contenuti misti (mixed content) non sono un errore del certificato, ma i visitatori spesso li percepiscono come tale. La pagina si carica in HTTPS, ma alcune risorse, come script, immagini, fogli di stile o iframe, vengono richieste in HTTP semplice. I browser bloccano del tutto script e frame non sicuri, il che può rompere il layout o le funzionalità, e possono mostrare la pagina senza il consueto indicatore di sicurezza.
Soluzione: sostituisci gli URL http:// scritti a mano nei template, nel database e nelle impostazioni con https:// o con URL relativi. Su WordPress, i contenuti misti derivano spesso da vecchi URL salvati nel contenuto dei post dopo il passaggio a HTTPS. Come rete di sicurezza, l’header Content-Security-Policy: upgrade-insecure-requests indica ai browser di richiedere invece quelle risorse in HTTPS.
Per trovare i contenuti misti prima dei visitatori, il monitoraggio dei link non funzionanti di Uptimecheck scansiona ogni giorno il tuo sito e la sua sitemap e segnala contenuti misti e link non funzionanti pagina per pagina.
Prevenire gli errori del certificato
La maggior parte degli errori del certificato sono errori di configurazione che correggi una volta sola. La scadenza è diversa: si ripresenta ogni volta che un certificato arriva a fine vita, e tende a colpire quando la persona che aveva configurato il rinnovo non c’è più. La prevenzione è una routine, non un intervento una tantum:
Tieni un inventario. Elenca ogni hostname che serve HTTPS, comprese API, pannelli di amministrazione, staging e siti dei clienti.
Automatizza il rinnovo ovunque puoi, e sappi dove è ancora manuale.
Controlla il certificato servito dopo ogni modifica. È con i traslochi del server, i nuovi load balancer e le modifiche DNS che i rinnovi si interrompono.
Monitora le date di scadenza per ricevere un promemoria settimane prima che un certificato scada, quando c’è ancora tempo per sistemare con calma un rinnovo che non va.
Tieni d’occhio anche il dominio e i suoi record. Un dominio scaduto o un record DNS modificato compromettono la convalida e, con essa, il sito.
Il monitoraggio SSL di Uptimecheck tiene traccia della data di scadenza del certificato servito su ogni dominio e sottodominio che monitori in HTTPS e invia promemoria ai tuoi canali di avviso prima che scada. È incluso in ogni piano. Abbinalo al monitoraggio della scadenza del dominio e al monitoraggio DNS, perché un certificato è affidabile solo quanto il dominio e i record che lo sostengono. La nostra guida al monitoraggio della scadenza dei certificati SSL contiene una checklist completa per il rinnovo e, se il browser non riesce nemmeno a trovare il tuo sito, leggi l’articolo su DNS_PROBE_FINISHED_NXDOMAIN.
Riepilogo
Ogni errore SSL è il browser che si rifiuta di fidarsi di una connessione: perché il certificato è scaduto, è stato emesso per un altro nome, è firmato da qualcuno che non conosce, è inviato senza la sua catena o è offerto con un protocollo che non accetta più. Controlla il certificato servito con openssl, correggi la configurazione, ricarica il server e controlla di nuovo. Poi fai in modo che la scadenza diventi un promemoria invece di un incidente.
Uptimecheck ti avvisa prima che certificati e domini scadano e ti segnala quando il tuo sito smette di rispondere. Provalo gratis per 14 giorni, senza carta di credito.