ERR_SSL_PROTOCOL_ERROR: la connessione sicura fallisce prima del certificato

Cosa significa l’errore

Una connessione HTTPS comincia con un saluto: il browser propone versioni di TLS e cifrari, il server sceglie e presenta il suo certificato. ERR_SSL_PROTOCOL_ERROR significa che quel saluto si è rotto. Chrome mostra “Questo sito non può fornire una connessione protetta”; Firefox “Errore durante la connessione sicura” con SSL_ERROR_RX_RECORD_TOO_LONG o SSL_ERROR_NO_CYPHER_OVERLAP. A differenza di “La connessione non è privata”, il browser non è neanche arrivato a valutare il certificato: non ha capito cosa ha inviato il server, oppure non ha trovato nessuna versione né cifrario in comune.

Le cause stanno quasi sempre sul server; i pochi casi dal lato del visitatore si escludono in un minuto.

Cause frequenti

1. Solo TLS vecchio. Il server accetta soltanto TLS 1.0 o 1.1, che i browser attuali non negoziano più.
2. Cifrari obsoleti. La lista dei cifrari esclude tutto ciò che il browser propone, per esempio dopo aver copiato una vecchia configurazione.
3. Certificato e chiave non corrispondono. Dopo un rinnovo, ssl_certificate punta al nuovo certificato e ssl_certificate_key alla vecchia chiave. nginx di solito si rifiuta di partire; Apache a volte parte e fallisce a ogni connessione.
4. La porta 443 parla HTTP. Manca ssl nella riga listen, oppure un servizio senza TLS è rimasto sulla 443. Il browser riceve testo in chiaro dove si aspettava TLS.
5. Proxy o CDN nella modalità sbagliata. Un proxy davanti inoltra all’origine in HTTPS, ma l’origine parla solo HTTP (o viceversa), oppure la modalità SSL del CDN non corrisponde al server.
6. SNI o vhost sbagliato. Il server non ha nessun blocco con certificato per quel nome e risponde con quello di un altro sito, o con nessuno.

Se sei un visitatore

1. Controlla data e ora del dispositivo.
2. Disattiva per un momento l’ispezione HTTPS dell’antivirus, il proxy o la VPN.
3. Svuota la cache SSL e i dati del sito nel browser, e prova in una finestra in incognito senza estensioni.
4. Prova http:// al posto di https://. Se così entra, il guasto è nell’HTTPS del sito e può correggerlo solo il proprietario.
5. Se l’errore compare anche da un altro dispositivo e da un’altra rete, non dipende da te.

Se è il tuo sito: verificare prima

Apri l’SSL checker: se nemmeno dall’esterno si riesce a stabilire una connessione TLS, il problema è sul server. Poi interroga con openssl, con il dominio come SNI:

# cosa negozia il server?
openssl s_client -connect example.com:443 -servername example.com </dev/null

# accetta TLS 1.2?
openssl s_client -connect example.com:443 -servername example.com -tls1_2 </dev/null

# c’è un server web in ascolto sulla 443, e quale?
sudo ss -tlnp | grep ':443 '
curl -sI http://example.com:443/ --max-time 5

Come leggere l’output: wrong version number o packet length too long significa che la 443 risponde in HTTP (causa 4); no protocols available o handshake failure, che non c’è nessuna versione né cifrario in comune (cause 1 e 2); key values mismatch nel log di nginx, che certificato e chiave non corrispondono (causa 3).

Soluzioni sul tuo server

1. Attivare solo TLS 1.2 e 1.3 con cifrari attuali

In nginx:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;

In Apache (mod_ssl):

SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLHonorCipherOrder off

Poi, sempre, provare e ricaricare:

sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2

2. Far corrispondere certificato e chiave

openssl x509 -noout -modulus -in /etc/letsencrypt/live/example.com/fullchain.pem | openssl md5
openssl rsa  -noout -modulus -in /etc/letsencrypt/live/example.com/privkey.pem  | openssl md5

Le due somme devono coincidere. Se no, punta ssl_certificate e ssl_certificate_key alla stessa cartella live/ di certbot (fullchain.pem e privkey.pem) e ricarica.

3. Far parlare TLS alla porta 443

Il blocco server che ascolta sulla 443 ha bisogno di ssl nella riga listen e di un certificato:

listen 443 ssl;
listen [::]:443 ssl;
ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Se ss -tlnp mostra un altro programma sulla 443 (un’applicazione Node, un pannello, un tunnel), spostalo su un’altra porta o mettilo dietro nginx.

4. Sistemare proxy o CDN

Con un reverse proxy davanti, la richiesta all’origine deve usare il protocollo che l’origine capisce: proxy_pass http://127.0.0.1:8080; se l’applicazione non ha TLS. Su un CDN, la modalità SSL deve corrispondere al server: con un certificato valido sull’origine, modalità completa e rigorosa. Verifica prima l’origine tramite il suo IP con -servername, poi il percorso attraverso il CDN.

5. Un blocco con certificato per ogni nome

Ogni nome da cui arrivano visitatori (example.com, www.example.com, sottodomini) ha bisogno di un blocco server con server_name e certificato, oppure di un certificato che li copra tutti:

sudo certbot --nginx -d example.com -d www.example.com --expand

Definisci inoltre un blocco predefinito per la 443 con certificato, così un nome sconosciuto riceve un errore di certificato chiaro e non un saluto rotto.

Se il problema è presso il tuo provider di hosting

Su un hosting condiviso la configurazione TLS è del provider. Se il pannello cliente mostra un certificato attivo e l’errore persiste dall’esterno, invia questo messaggio:

Buongiorno, da circa le 7:00 (UTC) i browser mostrano ERR_SSL_PROTOCOL_ERROR sul mio sito example.com e openssl s_client non completa il saluto TLS sulla porta 443. Il pannello cliente mostra un certificato attivo e non ho modificato nulla. Potete verificare la configurazione TLS del server e il certificato assegnato al mio dominio?

Perché non succeda di nuovo

Un errore di protocollo compare quasi sempre dopo un cambiamento: un rinnovo, un aggiornamento del server web, una configurazione copiata. Un controllo dall’esterno lo vede al primo tentativo, prima dei tuoi visitatori. Il monitoraggio dei certificati SSL tiene d’occhio anche scadenza, catena e nomi, così il prossimo avviso non sarà quello del browser.

Down? Interveniamo. Sul tuo server o su un hosting condiviso con accesso SSH, il Quick Fix rinnova il certificato dove certbot è configurato e ricarica il server web, a prezzo fisso, 24 ore su 24, anche nel fine settimana; il Deep Fix corregge la configurazione TLS, il proxy o i vhost, a blocchi di 15 minuti; la stima è il prezzo massimo.