Errori SSL: cosa sono e come risolverli

Un errore SSL è ciò che un browser mostra quando non riesce ad aprire una connessione crittografata attendibile con un sito web. Invece della pagina richiesta, viene visualizzata una schermata di avviso e un breve codice in caratteri piccoli, qualcosa come NET::ERR_CERT_AUTHORITY_INVALID o SSL_ERROR_NO_CYPHER_OVERLAP.

Quel codice è la parte utile, e la maggior parte delle guide lo trascura. “Errore SSL” non è un termine tecnico, e nessuno standard lo definisce come tale. È il nome comune per un’intera famiglia di errori diversi, motivo per cui consigli generici come svuotare la cache risolvono alcuni di essi e non fanno assolutamente nulla per gli altri.

Cosa è realmente un errore SSL

Quando carichi un indirizzo che inizia con https://, il tuo browser e il server eseguono una breve negoziazione chiamata handshake TLS prima che qualsiasi contenuto della pagina venga trasferito. L’handshake stabilisce una versione del protocollo e un insieme di algoritmi di crittografia, e il server dimostra la propria identità con un certificato. Se una qualsiasi parte di questo processo fallisce, il browser si rifiuta di continuare e mostra un errore invece della pagina.

SSL e TLS vale la pena distinguerli qui, perché la denominazione crea confusione reale. SSL è il protocollo originale, e ogni sua versione è stata deprecata da anni. Ciò che il tuo browser parla effettivamente è TLS. La parola “SSL” sopravvive nei nomi dei prodotti, nelle direttive di configurazione e nei codici di errore, motivo per cui la si vede ancora ovunque. Quando una pagina o un browser dice SSL, quasi sempre intende TLS.

Questo aspetto è importante per la risoluzione dei problemi perché la definizione comune di errore SSL è troppo restrittiva. Spesso si legge che un errore SSL significa che il browser non ha potuto verificare il certificato del sito. Questo è vero per un gruppo di questi errori e falso per il resto. Un server che risponde sulla porta HTTPS con testo semplice non crittografato produce un errore SSL e non invia mai alcun certificato. Due macchine che non riescono a concordare una cipher suite ne producono uno prima ancora che il certificato venga esaminato. Partire dal certificato quando il certificato non era mai stato il problema è il motivo più comune per cui le persone passano ore su una soluzione da cinque minuti.

Quale fase della connessione è fallita

Ogni connessione HTTPS attraversa la stessa sequenza, e un errore SSL è semplicemente il punto in cui quella sequenza si è interrotta. Capire la fase riduce immediatamente il campo delle cause, perché ogni fase ha un insieme completamente diverso di spiegazioni.

1. La connessione non è mai diventata TLS. Il tuo browser ha aperto una connessione e ciò che è tornato non era TLS, oppure l’altra estremità ha chiuso la connessione prima che l’handshake terminasse. Nessun certificato è coinvolto, e nessun certificato deve essere sostituito.
2. L’handshake è fallito durante la negoziazione. Entrambe le parti parlavano TLS ma non sono riuscite a concordare una versione del protocollo, una cipher suite, o quale sito veniva richiesto. L’handshake si interrompe prima che il certificato venga validato, e spesso prima che venga persino inviato.
3. Il certificato è stato ricevuto e rifiutato. Questo è il gruppo a cui le persone si riferiscono quando dicono “errore SSL”. Scadenza, coperture di hostname, catena di fiducia, revoca e robustezza della firma rientrano tutti qui.
4. L’handshake è riuscito e qualcosa dopo di esso è fallito. La connessione crittografata è stata stabilita correttamente, poi un livello successivo si è rotto. A questo punto il certificato viene confermato valido, quindi sostituirlo non cambia nulla.

Non è necessario indovinare in quale fase ti trovi. Il codice di errore te lo indica, e la sezione successiva mappa ogni codice alla propria fase.

Trova il tuo errore

Leggi il codice riportato sotto il messaggio di avviso. In Chrome ed Edge si trova in caratteri piccoli sotto “La connessione non è privata”. In Firefox potrebbe essere necessario aprire i dettagli avanzati nella pagina di avviso. Poi trovalo qui sotto.

Fase 1: la connessione non è mai diventata TLS

• SSL_ERROR_RX_RECORD_TOO_LONG in Firefox significa che il server ha risposto a una richiesta HTTPS con qualcosa che non è TLS, quasi sempre HTTP semplice servito sulla porta 443. È un problema di configurazione del server.
• PR_END_OF_FILE_ERROR in Firefox significa che l’altra estremità ha chiuso la connessione prima che l’handshake si completasse. La causa si trova spesso tra te e il server piuttosto che a una delle due estremità.

Fase 2: l’handshake è fallito durante la negoziazione

• ERR_SSL_PROTOCOL_ERROR è il codice generico di Chrome per un handshake fallito per un motivo che non è riuscito a identificare con precisione. Inizia da qui se il tuo codice è questo, perché il primo compito è restringere il campo.
• SSL_ERROR_NO_CYPHER_OVERLAP è l’equivalente di Firefox, ed è altrettanto generico: appare per qualsiasi fallimento fatale dell’handshake segnalato dal server, qualunque fosse la reale motivazione del server.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH è il codice di Chrome per la stessa classe di fallimento, generato per un elenco breve e specifico di condizioni di negoziazione.
• ERR_SSL_UNRECOGNIZED_NAME_ALERT significa che il server ha terminato l’handshake intenzionalmente perché l’hostname richiesto non corrisponde a nessun sito configurato su di esso. Nessun certificato viene inviato, quindi il certificato non è la causa.
• ERR_BAD_SSL_CLIENT_AUTH_CERT funziona in direzione opposta rispetto a tutti gli altri errori qui elencati: il sito ha richiesto un certificato al tuo browser e ha rifiutato quello ricevuto, oppure non ne ha ricevuto nessuno. Questo è davvero un errore risolvibile sulla tua macchina.
• L’errore Cloudflare 525 è un fallimento dell’handshake su un tratto diverso del percorso: tra Cloudflare e il server di origine dietro di esso, non tra il tuo browser e Cloudflare. I visitatori non possono agire su di esso.

Fase 3: il certificato è stato ricevuto e rifiutato

La connessione non è privata è la schermata di avviso di Chrome per tutto questo gruppo piuttosto che una causa a sé stante, quindi se è tutto ciò che hai, leggi prima il codice sottostante.

La catena di fiducia non ha potuto essere costruita. Il browser non è riuscito a collegare il certificato del sito a una radice di cui si fida, di solito perché il server invia il proprio certificato omettendo l’intermedio sopra di esso.

• NET::ERR_CERT_AUTHORITY_INVALID in Chrome ed Edge.
• SEC_ERROR_UNKNOWN_ISSUER in Firefox, la stessa condizione con un nome diverso.
• Un certificato intermedio scaduto, dove la catena esiste ma un collegamento sopra di te è scaduto.
• MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT, dove non esiste catena perché il certificato ha firmato se stesso.

Le date o il nome non corrispondono. Il certificato è affidabile ma non si applica a questo momento o a questo hostname.

• NET::ERR_CERT_DATE_INVALID, dove il certificato è scaduto o non è ancora valido. Vale la pena sapere che anche un orologio impostato in modo errato sul proprio dispositivo può produrre questo errore.
• NET::ERR_CERT_COMMON_NAME_INVALID, dove l’hostname non è elencato nel certificato.
• DLG_FLAGS_SEC_CERT_CN_INVALID, lo stesso problema di hostname segnalato da software basato sul più vecchio stack web di Windows, principalmente la modalità Internet Explorer in Edge e le applicazioni aziendali interne.

Il certificato è affidabile e valido ma è escluso per un altro motivo.

• NET::ERR_CERT_REVOKED, dove la Certificate Authority lo ha annullato prima della sua data di scadenza.
• NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED, dove il certificato non è arrivato con prove pubbliche sufficienti di rilascio.
• NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM, dove qualcosa nella catena è firmato con SHA-1. Le versioni recenti di Chrome potrebbero segnalare lo stesso certificato con un codice diverso, ma la condizione e la soluzione restano invariate.
• SEC_ERROR_REUSED_ISSUER_AND_SERIAL, una collisione all’interno dell’archivio certificati di Firefox stesso piuttosto che un difetto nella connessione.
• NET::ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN, che si applica a un insieme molto piccolo di domini integrati nel browser, quindi un sito web ordinario non può produrlo.

Il file del certificato stesso è errato. Questi due si trovano sul server piuttosto che in un browser, e di solito impediscono a un sito di servire HTTPS del tutto.

• ERR_SSL_SERVER_CERT_BAD_FORMAT, dove il browser non è riuscito a decodificare il certificato inviato dal server.
• Una mancata corrispondenza del modulo, dove il certificato installato non appartiene alla chiave privata installata.

Fase 4: l’handshake è riuscito e qualcosa dopo di esso è fallito

Questi sono classificati come errori SSL per abitudine. In ogni caso la connessione crittografata funzionava già, quindi il certificato è stato validato con successo e reissuirlo non aiuterebbe.

• ERR_SSL_BAD_RECORD_MAC_ALERT significa che il server ha ricevuto dati crittografati che non è riuscito a verificare, cosa che avviene dopo l’handshake sotto le chiavi di sessione. Qualcosa nel percorso sta corrompendo o riscrivendo il traffico.
• ERR_QUIC_PROTOCOL_ERROR è un fallimento di QUIC, il trasporto sottostante a HTTP/3. Non è un problema di certificato, e la causa abituale è un firewall o una VPN che filtra UDP.
• ERR_SPDY_PROTOCOL_ERROR è un fallimento a livello HTTP/2, che si trova sopra un handshake TLS completato.
• Il contenuto misto è il caso anomalo: la pagina si è caricata perfettamente tramite HTTPS, poi ha richiesto una risorsa tramite HTTP semplice. Non produce alcuna pagina di errore, solo un lucchetto degradato e script o immagini mancanti.

Errori denominati in base a un dispositivo piuttosto che a una fase

Due piattaforme producono abbastanza peculiarità proprie da meritare un trattamento separato, perché la stessa condizione sottostante si comporta diversamente su di esse.

• Errori SSL su iPhone e iPad, incluso il messaggio “Si è verificato un errore SSL e non è possibile stabilire una connessione sicura al server”. L’impostazione di data e ora è la prima cosa da controllare.
• Errori di connessione SSL su Android, dove Chrome e altre app consultano archivi di fiducia diversi, e un certificato intermedio mancante causa più problemi di quanti ne causi su desktop.

Codici che non compaiono più

Tre codici sono ancora ampiamente documentati ma sono stati rimossi dai browser che li producevano, quindi se stai leggendo consigli su uno di essi, controlla la data. Le condizioni dietro due di essi esistono ancora sotto altri nomi.

• NET::ERR_CERT_SYMANTEC_LEGACY è stato eliminato in Chrome 136, rilasciato ad aprile 2025.
• ERR_SSL_VERSION_INTERFERENCE è stato rimosso in Chrome 76 nel 2019, sebbene l’interferenza che descriveva continui a verificarsi e ora si manifesti in modo diverso.
• ERR_SPDY_PROTOCOL_ERROR è stato rinominato in ERR_HTTP2_PROTOCOL_ERROR in Chrome 77, sempre nel 2019. Il fallimento che descrive è ancora attuale, motivo per cui è elencato sotto la fase quattro sopra.

Se stai visitando il sito

La maggior parte degli errori SSL è responsabilità del sito web da risolvere, e nessuna quantità di lavoro sul proprio dispositivo li cambierà. Esiste un breve elenco di vere eccezioni, e vale la pena esaminarlo prima di concludere che il sito sia rotto.

• Controlla il tuo orologio. La validazione del certificato confronta le date del certificato con l’orario del tuo dispositivo. Un orologio sbagliato di mesi o anni fa apparire non valido ogni certificato, ed è la causa singola più comune sul lato visitatore.
• Prova una seconda rete. Passare dal Wi-Fi ai dati mobili, o viceversa, ti dice in pochi secondi se qualcosa sulla rete sta intercettando il traffico. Il Wi-Fi pubblico e degli hotel sono colpevoli frequenti.
• Disattiva temporaneamente la scansione HTTPS. I prodotti antivirus e i proxy aziendali ispezionano il traffico crittografato sostituendo i propri certificati. Quando lo fanno male, ottieni un errore SSL su siti che funzionano bene altrove.
• Prova una finestra privata e un altro browser. Se l’errore appare in un browser e non in un altro, la causa è di solito locale, in un’estensione o nei dati memorizzati. Se appare in tutti, è il sito.

Se nulla di tutto ciò aiuta, il problema è sul server e la risposta onesta è che non puoi risolverlo. Questo si applica completamente all’errore Cloudflare 525, dove il fallimento avviene su una connessione di cui il tuo browser non fa parte.

I browser offrono effettivamente un modo per procedere oltre la maggior parte degli avvisi sui certificati, e vale la pena essere chiari su cosa questo costa. Procedere significa dire al browser di accettare una connessione la cui identità non è riuscito a verificare, il che significa che non hai alcuna garanzia di stare parlando con il sito che hai digitato piuttosto che con qualcosa nel mezzo. Questo è un compromesso accettabile su un server di test che controlli. Non è accettabile su nulla dove inserirai una password o un dettaglio di pagamento. Alcuni errori non offrono alcun modo per procedere, e ciò è deliberato piuttosto che un difetto.

Se gestisci il sito web

Diagnostica prima di cambiare qualsiasi cosa. Reinstallare un certificato che non era mai stato il problema è il modo abituale in cui un’ora diventa un pomeriggio.

Inizia con un controllo esterno

Esegui il controllo del dominio con il nostro SSL Checker. Segnala ciò che il server sta effettivamente inviando al mondo esterno, il che è frequentemente diverso da ciò che si trova nel file di configurazione. Una catena che appare completa su disco ma arriva incompleta al browser è il riscontro più comune, ed è la causa dietro sia NET::ERR_CERT_AUTHORITY_INVALID che SEC_ERROR_UNKNOWN_ISSUER.

Puoi vedere la stessa cosa dalla riga di comando. Questo stampa ogni certificato offerto dal server, nell’ordine in cui li offre:

openssl s_client -connect example.com:443 -servername example.com -showcerts

Leggi l’elenco dei certificati in quell’output, non la riga Verify return code in fondo. Quella riga è molto meno informativa di quanto sembri: riporta solo il verdetto di OpenSSL sulla catena, ignora l’hostname a meno che tu non richieda esplicitamente quel controllo, e stampa 0 (ok) anche quando il server non ha inviato alcun certificato perché l’handshake è stato interrotto. Se l’output dice no peer certificate available invece di mostrare una riga subject=, nulla è stato verificato e il fallimento è avvenuto prima.

Controlla le date e l’hostname

Questi due rappresentano una grande parte dei rifiuti di certificato. Per leggere la finestra di validità del certificato che il server sta servendo:

openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -dates -subject

I browser confrontano l’hostname con l’estensione subjectAltName e ignorano completamente il Common Name, quindi quello è il campo da esaminare su un file di certificato locale:

openssl x509 -noout -text -in certificate.crt | grep -A1 "Subject Alternative Name"

Per far applicare a OpenSSL il controllo dell’hostname che un browser applica, aggiungi il flag piuttosto che assumere che un risultato pulito lo includa già:

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com

Su macOS questi comandi richiedono attenzione. L’openssl distribuito con macOS è LibreSSL, e rifiuta completamente -verify_hostname e riporta un risultato sano su alcune catene realmente rotte. Installa OpenSSL tramite Homebrew, poi esegui nuovamente openssl version per confermare quale binario stai effettivamente chiamando. Se riporta ancora LibreSSL, il tuo PATH sta trovando prima la copia di sistema, quindi chiama /opt/homebrew/bin/openssl con il suo percorso completo.

Poi correggi e verifica

Cosa cambiare dipende dalla fase, e le guide individuali collegate sopra riportano i passaggi specifici per piattaforma. Tre correzioni coprono la maggior parte dei casi:

• Servi la catena completa. Concatena il tuo certificato e i certificati intermedi forniti dalla tua Certificate Authority nel file a cui punta il tuo server. Non inserire la chiave privata in quel file.
• Rinnova prima della scadenza, e automatizza. Le durate dei certificati si stanno riducendo, quindi qualsiasi cosa rinnovata manualmente verrà alla fine rinnovata in ritardo. L’automazione ACME elimina la scadenza.
• Coprine ogni hostname che servi effettivamente. Un certificato per un dominio non coprine i suoi sottodomini a meno che non sia un wildcard o li elenchi.

Testa sempre la configurazione prima di ricaricare il servizio, e riesegui il controllo in seguito dall’esterno della tua rete. Una correzione confermata solo nel browser in cui hai testato non è confermata, perché quel browser potrebbe conservare un risultato nella cache.

Come prevenire gli errori SSL

Quasi ogni errore SSL su un sito web funzionante deriva da una di tre cose: un certificato scaduto, una catena che non è mai stata completa, o una configurazione che si è deteriorata nel tempo. Tutte tre sono prevenibili.

• Automatizza il rinnovo. Le durate massime dei certificati vengono ridotte a fasi nei prossimi anni, e il rinnovo manuale smette di essere praticabile ben prima della fine di quel periodo. Automatizza ora piuttosto che quando si rompe.
• Monitora la scadenza in modo indipendente. Un promemoria sul calendario fallisce quando la persona se ne va. Un controllo esterno che ti avvisa settimane prima non lo fa.
• Riesegui il controllo dopo ogni modifica. Le migrazioni di server, i cambiamenti CDN e gli aggiornamenti del pannello di controllo riscrivono tutti silenziosamente la configurazione del certificato. Verifica dall’esterno in seguito.
• Testa su un telefono, non solo su un desktop. Le piattaforme mobili sono più rigide riguardo alle catene incomplete, quindi un problema di catena spesso si manifesta su un telefono mentre il desktop appare a posto.
• Installa correttamente la prima volta. I nostri tutorial di installazione trattano i passaggi di catena e binding per piattaforma, e la maggior parte degli errori di catena ha origine al momento dell’installazione.

Domande frequenti