ERR_SSL_PROTOCOL_ERROR: cosa significa e come risolverlo

Cosa significa ERR_SSL_PROTOCOL_ERROR

Una connessione TLS inizia con un handshake: il client invia un ClientHello che elenca le versioni di protocollo e le suite di cifratura che supporta, e il server dovrebbe rispondere con un ServerHello che ne sceglie una, seguito dal proprio certificato. ERR_SSL_PROTOCOL_ERROR scatta quando quello scambio si interrompe prima di raggiungere il passaggio del certificato, il più delle volte perché qualunque cosa rispondesse sulla porta non stava affatto parlando TLS, oppure le due parti non sono riuscite a mettersi d'accordo su come parlarlo. Questo è il termine di ricerca per codice di errore con più traffico in assoluto per Chrome, e il volume riflette quante cause radice diverse collassino nello stesso messaggio generico piuttosto che un unico fallimento comune.

Come appare l'errore

Chrome ed Edge mostrano ERR_SSL_PROTOCOL_ERROR senza dettagli sul certificato, perché nessun certificato è mai stato presentato da mostrare. Firefox tipicamente mostra "Secure Connection Failed" con un codice come SSL_ERROR_RX_MALFORMED_HANDSHAKE o SSL_ERROR_PROTOCOL_VERSION_ALERT a seconda di come si è interrotto l'handshake.

Dalla riga di comando, sia curl sia openssl identificano il fallimento con precisione, il che è il modo più veloce per andare oltre una supposizione:

curl -v https://example.com/
...
* TLSv1.3 (OUT), TLS handshake, Client hello
* OpenSSL/3.x: error:0A000126:SSL routines::unexpected eof while reading
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL

openssl s_client -connect example.com:443 -servername example.com
...
140... error:1408F10B:SSL routines:ssl3_get_record:wrong version number

"Wrong version number" significa quasi sempre che la porta 443 ha risposto con HTTP semplice, non TLS, dato che i primi byte di una risposta HTTP sembrano dati corrotti a un parser TLS che si aspetta un ServerHello. Una connessione che si blocca e va in timeout senza alcun errore, invece di fallire rapidamente, di solito significa che un firewall o un proxy sta scartando silenziosamente i pacchetti invece che il server li rifiuti attivamente.

Cosa causa ERR_SSL_PROTOCOL_ERROR

• La porta 443 sta servendo HTTP semplice, o un servizio completamente sbagliato. Un reverse proxy mal configurato, un servizio andato in crash che ha lasciato dietro un listener di fallback, o una regola NAT puntata al backend sbagliato producono tutti una risposta non TLS sulla porta TLS.
• Mismatch di versione TLS o di cifratura. Un server bloccato su TLS 1.0 o 1.1 per conformità legacy non condivide alcun protocollo comune con un browser che richiede TLS 1.2 o superiore, quindi l'handshake fallisce del tutto.
• Server Name Indication (SNI) mancante o mal configurato. Su un server che ospita più certificati su un solo IP, una corrispondenza SNI mancante può fargli presentare il certificato sbagliato o rifiutare l'handshake.
• Esperimenti QUIC e HTTP/3. Chrome a volte prova prima QUIC e ripiega su TLS su TCP; una rete che gestisce male il traffico UDP di QUIC può manifestarsi come errore di protocollo sul tentativo di fallback.
• Scansione HTTPS di antivirus o proxy aziendali. Il software che intercetta il TLS per ispezionare il traffico avvia il proprio handshake al posto di quello reale, e un certificato di intercettazione rotto rompe quel sostituto.
• HSTS che forza HTTPS su un host il cui TLS è rotto. Una volta che un browser ha messo in cache una policy HSTS per un dominio, non tenterà mai HTTP semplice, quindi un host che una volta ripiegava con grazia ora fallisce del tutto.
• Una catena di certificati vecchia o rotta, su un client vecchio. Sistemi operativi e browser molto vecchi che precedono una root o un intermedio più recente possono far fallire l'handshake in modi indistinguibili da un mismatch di versione.
• L'orologio del client è molto sbagliato. Un orologio abbastanza fuori sincrono può far sì che un client si rifiuti del tutto di negoziare una sessione, non solo di rifiutare il certificato in seguito.

Come capire di chi è la colpa

Esegui la stessa richiesta da una seconda rete, per esempio un telefono sui dati mobili invece del Wi-Fi dell'ufficio. Se il sito si carica correttamente lì, il problema è locale: un proxy aziendale, un'intercettazione antivirus, o un captive portal sulla prima rete. Se l'handshake fallisce in modo identico ovunque tu lo provi, la configurazione TLS del server è la causa. Un controllo SSL eseguito da più postazioni contemporaneamente risponde a questo in una singola richiesta invece di prendere in prestito un secondo dispositivo, e riporta il protocollo e la cifratura esatti che il server ha negoziato (o rifiutato) da ciascun punto di osservazione.

Come correggere ERR_SSL_PROTOCOL_ERROR

Se sei un visitatore

1. Cancella lo stato TLS di Chrome su chrome://net-internals/#hsts e chrome://restart, oppure cancella semplicemente i dati di navigazione per "immagini e file memorizzati nella cache" più "cookie e dati dei siti" per il sito interessato, il che cancella anche lo stato HSTS e di sessione SSL in cache.
2. Disattiva l'esperimento QUIC su chrome://flags/#enable-quic, impostalo su Disabled, e riavvia il browser. Se il sito si carica dopo, la causa era una rete o un proxy non compatibile con QUIC.
3. Controlla la data e l'ora di sistema e impostale per la sincronizzazione automatica; un orologio abbastanza fuori sincrono può rompere l'handshake del tutto, non solo il controllo del certificato che viene dopo.
4. Disattiva la scansione HTTPS nel tuo antivirus (comunemente sotto un'impostazione "protezione web" o "scansione SSL/TLS") e riprova. Se questo lo risolve, aggiorna l'antivirus oppure aggiungi il sito alla sua lista di esclusione invece di lasciare la scansione disattivata del tutto.
5. Prova un'altra rete, come i dati mobili. Un proxy aziendale o un pezzo di hardware di rete rotto che colpisce solo una connessione è una causa comune che non ha nulla a che fare con il sito stesso.

Se gestisci il sito

1. Conferma che la porta 443 sia effettivamente TLS con il comando openssl sopra. "Wrong version number" o una risposta in testo semplice significa che il servizio sbagliato è associato a quella porta; correggi la configurazione del proxy o del listener prima di toccare affatto i certificati.
2. Imposta esplicitamente le versioni di protocollo supportate. Su nginx:

   ssl_protocols TLSv1.2 TLSv1.3;
   ssl_ciphers HIGH:!aNULL:!MD5;

   Eliminare TLS 1.0 e 1.1 corregge gli handshake dei client moderni ma romperà l'accesso da client molto vecchi che ancora vi fanno affidamento; decidi quel compromesso deliberatamente e non per caso.
3. Conferma che il server block sia effettivamente in ascolto per TLS sulla porta che ti aspetti: listen 443 ssl; (o listen 443 ssl http2;) e che le direttive certificate e key puntino a file che esistono e corrispondono tra loro.
4. Controlla l'ordine della catena di certificati. Il certificato foglia deve venire per primo, seguito dagli intermedi in ordine fino alla (ma non includendo la) root; una catena servita fuori ordine o a cui manca un intermedio causa fallimenti dell'handshake su alcuni client mentre funziona su altri che mettono in cache l'intermedio mancante altrove.
5. Se il dominio si trova dietro Cloudflare, controlla la modalità SSL/TLS. La modalità Flexible termina il TLS all'edge e parla HTTP semplice con l'origine, il che fallisce del tutto se l'origine accetta solo HTTPS; la modalità Full richiede qualunque certificato all'origine; Full (strict) richiede un certificato valido e affidabile all'origine e produrrà essa stessa fallimenti dell'handshake se il certificato dell'origine è autofirmato o scaduto.
6. Ricarica, non limitarti a modificare, dopo qualunque cambio di configurazione: nginx -t && systemctl reload nginx convalida la configurazione prima di applicarla.

ERR_SSL_PROTOCOL_ERROR contro errori dall'aspetto simile

• ERR_CERT_DATE_INVALID avviene dopo che un certificato è stato ricevuto e letto; l'handshake è arrivato fin lì e poi ha fallito un confronto di date. ERR_SSL_PROTOCOL_ERROR non arriva mai così lontano.
• ERR_CERT_AUTHORITY_INVALID avviene anch'esso dopo che un certificato è stato ricevuto; il browser lo ha letto e non si è fidato di chi lo ha firmato. Di nuovo, un errore di protocollo significa che nessun certificato è mai stato giudicato.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH è il fratello più specifico di questo errore: scatta quando l'handshake è effettivamente proceduto abbastanza da confrontare versioni e cifrature supportate, e non ha trovato alcuna sovrapposizione, tipicamente un vecchio server che offre solo SSLv3 o TLS 1.0 contro un browser moderno che li rifiuta. ERR_SSL_PROTOCOL_ERROR è il fallimento più ampio e meno specifico che copre tutto il resto, inclusa una risposta non TLS sulla porta, dati di handshake malformati, e software di intercettazione andato storto.

Come prevenire ERR_SSL_PROTOCOL_ERROR

Un fallimento dell'handshake introdotto da un cambio di configurazione, un aggiornamento del proxy, o un cambio di modalità SSL di Cloudflare non compare in un normale controllo di stato HTTP, dato che la connessione non arriva mai abbastanza lontano da produrne uno. Un controllo SSL dedicato legge direttamente il protocollo e la cifratura negoziati e, eseguito da oltre 300 punti di controllo in 158 città, mostra se l'handshake fallisce ovunque o solo da una rete, la stessa distinzione che questa guida percorre a mano. Esegui un controllo del certificato SSL contro il dominio, e imposta un monitoraggio continuo SSL e di scadenza del dominio in modo che un handshake rotto avvisi prima che i visitatori lo segnalino.

Domande frequenti

ERR_SSL_PROTOCOL_ERROR significa che il mio certificato è cattivo?

Non necessariamente. L'errore scatta prima che il browser raggiunga il certificato, quindi il certificato stesso potrebbe essere completamente a posto mentre la negoziazione TLS sottostante fallisce comunque.

Perché questo succede solo su un computer o una rete?

La scansione HTTPS dell'antivirus, un proxy aziendale, o un percorso QUIC rotto su quella specifica rete sono i motivi abituali per cui un handshake fallisce in un posto e riesce ovunque altro. Testare da una seconda rete è il modo più veloce per confermarlo.

Ho appena spostato il mio sito dietro Cloudflare e ora i visitatori vedono questo. Cosa è cambiato?

Controlla la modalità SSL/TLS nella dashboard. La modalità Flexible si aspetta che l'origine accetti HTTP semplice e fallisce se serve solo HTTPS; Full (strict) si aspetta un certificato di origine valido e affidabile e fallisce su uno autofirmato o scaduto.

Disattivare TLS 1.0 e 1.1 sul mio server rompe qualcosa?

Può succedere, per i visitatori su browser molto vecchi che non hanno mai ricevuto un aggiornamento a TLS 1.2. Per la maggior parte del traffico attuale corregge più handshake di quanti ne rompa, ma controlla prima il mix dei tuoi client.

Perché curl ha detto "wrong version number"?

Quel messaggio significa che curl ha inviato un ClientHello TLS e ha ricevuto indietro byte che non vengono interpretati come un ServerHello TLS, quasi sempre perché la porta sta servendo HTTP semplice o un altro protocollo non TLS.