Cosa significa ERR_SSL_PROTOCOL_ERROR, e perché non dice di chi è la colpa

Qualcuno vi dice che il vostro sito non carica e vi manda un codice: ERR_SSL_PROTOCOL_ERROR. A voi funziona. A tutti in ufficio funziona. La pagina che quella persona ha davanti è grigia, contiene circa due frasi e non offre nient’altro.

Questa è la descrizione che Chromium dà di quell’errore, nel file in cui è definito ogni errore di rete di Chrome:

An SSL protocol error occurred.

È tutto il commento. Cinque parole, per l’errore numero -107. Non è una versione accorciata di qualcosa di più lungo; è tutto quello che il browser ha.

È il codice che Chrome usa quando non può essere più preciso

Ciò che rende la cosa importante è quello che gli sta intorno nella stessa lista.

Poche righe più avanti c’è ERR_SSL_VERSION_OR_CIPHER_MISMATCH, il numero -113, e la sua descrizione è precisa: “The client and server don’t support a common SSL protocol version or cipher suite.” Più in là c’è un intero intervallo per i certificati, dove ERR_CERT_COMMON_NAME_INVALID, il numero -200, porta quattro cause con un nome, compresa quella in cui la persona è su una rete senza fili e viene reindirizzata alla pagina di accesso della rete.

Quindi Chrome ha codici più precisi per i guasti che sa attribuire. Ricevere -107 invece significa che l’handshake è fallito in un modo a cui il browser non ha saputo dare un nome.

È il contrario di come questo errore viene trattato di solito. Ogni guida sul tema è un elenco di otto cose da provare, e la lunghezza dell’elenco è l’indizio: nessuno che ne scriva uno sa quale delle otto si applichi, perché l’errore non lo dice.

Cosa fallisce davvero, e quanto poco di quello è vostro

La pagina di risoluzione dei problemi di Cloudflare dedicata a questo errore elenca quello che loro vedono dietro. Il loro riassunto è che l’handshake è fallito, e le ragioni che nominano sono:

• Un problema di certificato, per esempio un certificato non ancora attivo, o un sottodominio su più livelli che il certificato presente non copre.
• Una suite di cifratura che non combacia, dove, con le loro parole, i client più vecchi potrebbero non supportare le suite moderne.
• HTTP/3 e QUIC bloccati, da una rete, un firewall o un apparato che non porta QUIC su UDP.
• TLS 1.3 non supportato del tutto da apparati di sicurezza di rete che fanno ispezione SSL.
• Interferenze di rete: ispezione profonda dei pacchetti, proxy che intercettano, controlli parentali, NAT di operatore.

Questa è la visione di un CDN dalla propria coda di assistenza e non una tassonomia completa, e resta l’elenco più utile disponibile, per come si suddivide.

Contate a chi appartiene ciascuna voce. La prima è vostra. La seconda è del browser o del sistema operativo di chi segnala. La terza, la quarta e la quinta sono di apparati e software che stanno fra quella persona e voi: il suo router, l’appliance di ispezione della sua azienda, il suo antivirus, il suo operatore.

Una su cinque sta dalla vostra parte, e il testo dell’errore è identico per tutte.

Ed è per questo che la segnalazione arriva inutilizzabile

“Il vostro sito è rotto, ERR_SSL_PROTOCOL_ERROR” è una descrizione completa di quello che quella persona riesce a vedere e non vi dice quasi niente. La domanda ovvia successiva, se riguardi solo lei, è proprio quella a cui non potete rispondere da dove siete: la vostra macchina è su un’altra rete, dietro un altro hardware, con un altro software di sicurezza, e negozia forse con un altro nodo di bordo.

È lo stesso problema di distinguere il vostro bug dal disservizio di qualcun altro, e ha la stessa proprietà: la prova che lo chiarirebbe esiste solo sulla loro macchina e solo mentre sta succedendo.

Non è l’avviso sul certificato, e la differenza è grande

Se chi segnala descrive una pagina rossa che la avverte che la connessione non è privata, con un codice che inizia per ERR_CERT_, quello è un altro errore e molto più trattabile: quei codici dicono il proprio motivo, e quale dei cinque sia si chiarisce in un minuto.

ERR_SSL_PROTOCOL_ERROR non ha quella pagina né quel motivo. Vale la pena stabilire quale dei due ha visto davvero prima di passare un pomeriggio su quello sbagliato, e la via più rapida è chiedere lo screenshot invece della descrizione.

I due test che dividono il campo

La pagina di Cloudflare chiude il proprio consiglio dicendo di raccogliere dati diagnostici dai visitatori interessati, che è la forma onesta della risposta. Prima di quello, due cose che chi segnala può fare in un minuto restringono il campo più di qualunque cosa possiate eseguire voi.

Chiedetele di provare in rete mobile, con il wifi spento. Se la pagina carica, il problema sta fra la sua rete e voi, e nessuna modifica sul vostro server lo risolverà per lei. Se continua a fallire, la sua rete non è la causa.

Chiedetele di provare un altro browser sulla stessa macchina. Se lì carica, la causa è il suo browser: il suo supporto dei protocolli, il suo archivio di certificati, o un’estensione che gli sta davanti. Se fallisce in entrambi, sono coinvolti la macchina o la sua rete, non il browser.

Quelle due risposte insieme coprono quattro delle cinque cause qui sopra e costano a quella persona circa novanta secondi. Quello che volete annotato di fianco: l’URL completo, se è stato scritto http o https, il codice esatto, l’ora, e se nello stesso minuto stesse fallendo qualcos’altro.

Il caso che è vostro e sembra loro

Uno schema vale la pena di conoscerlo perché produce esattamente questo errore dalla vostra parte pur somigliando a un problema del client. Un certificato valido ma non ancora attivo, perché la sua data di inizio è nel futuro, fa fallire l’handshake invece di produrre una pagina di avviso, e fallisce per tutti quelli che hanno l’orologio giusto. Lo stesso vale per un host che sta un livello più in basso di quanto il certificato copra: app.eu.example.com contro un certificato emesso per *.example.com non è coperto, perché un singolo wildcard combacia con una etichetta.

Entrambi sono una vostra correzione, entrambi arrivano come questo errore, e nessuno dei due si distingue da un problema di apparato intermedio senza controllare il certificato che il vostro bordo sta servendo davvero.

Cosa portarsi via

ERR_SSL_PROTOCOL_ERROR non è una diagnosi. È la sua assenza, e Chromium lo dice esattamente in cinque parole. Prendetelo come il browser che vi dice che un handshake è fallito e che non è riuscito a capire perché, e mettete poi la vostra fatica nelle due domande che dividono le cause, invece che nell’elenco di otto correzioni di cui sette non si sarebbero mai applicate.