ERR_SSL_PROTOCOL_ERROR: cause e soluzioni

ERR_SSL_PROTOCOL_ERROR appare quando il browser non riesce a completare correttamente la connessione HTTPS con il sito. Il problema si verifica durante la negoziazione SSL/TLS oppure quando il server restituisce sulla porta 443 una risposta incompatibile con il protocollo atteso.

Il messaggio non indica necessariamente che il certificato sia scaduto. Può dipendere anche da una configurazione errata del server, da protocolli incompatibili, da un proxy che intercetta il traffico oppure da un problema tra Cloudflare e il server di origine.

Indice

• Che cosa significa ERR_SSL_PROTOCOL_ERROR
• Differenze rispetto agli altri errori SSL
• Come capire se il problema è locale o del sito
• Soluzioni per chi visita il sito
• Controlli per il proprietario del sito
• Diagnosi con OpenSSL e curl
• AutoSSL e cPanel
• LiteSpeed, Apache e Nginx
• Cloudflare: errori 525 e 526
• ERR_SSL_PROTOCOL_ERROR su WordPress
• Checklist finale
• Domande frequenti

Che cosa significa ERR_SSL_PROTOCOL_ERROR

HTTPS protegge la comunicazione tra browser e server attraverso TLS, successore del vecchio protocollo SSL. Prima di inviare la pagina, client e server devono completare un handshake: concordano il protocollo, verificano il certificato, selezionano gli algoritmi crittografici e stabiliscono le chiavi della sessione.

ERR_SSL_PROTOCOL_ERROR indica che questo processo non è terminato correttamente. Cloudflare descrive l’errore come un fallimento dell’handshake SSL/TLS che può dipendere da certificati, incompatibilità di protocollo o interferenze di rete.

Le cause più comuni sono:

• data e ora del dispositivo non corrette;
• browser o sistema operativo obsoleto;
• VPN, proxy, filtro aziendale o antivirus che intercettano HTTPS;
• porta 443 non configurata per TLS;
• certificato scaduto, non ancora valido o non corrispondente al dominio;
• catena di certificazione incompleta;
• chiave privata non corrispondente al certificato;
• certificato installato sul virtual host sbagliato;
• SNI configurato in modo errato;
• web server che espone protocolli o cifrari incompatibili;
• record DNS A o AAAA diretti verso un server differente;
• modalità SSL/TLS Cloudflare non coerente con il certificato di origine;
• firewall o dispositivo intermedio che interrompe l’handshake;
• rinnovo AutoSSL non completato o dominio escluso dalla copertura.

Differenze rispetto agli altri errori SSL

Se il dominio non viene risolto, il problema è differente: consulta la guida a DNS_PROBE_FINISHED_NXDOMAIN e l’approfondimento sui record DNS.

Come capire se il problema è locale o dipende dal sito

Prima di intervenire sul server, esegui alcuni test semplici:

1. Apri altri siti HTTPS: se falliscono tutti, controlla dispositivo, rete, antivirus, proxy o data e ora.
2. Prova un altro browser: se il sito funziona, il problema può riguardare cache, estensioni o configurazione del browser.
3. Usa un altro dispositivo sulla stessa rete: se fallisce anche quello, verifica router, DNS o filtri di rete.
4. Prova la rete mobile: se il sito funziona, il problema potrebbe dipendere dal Wi-Fi, dal provider o da un proxy locale.
5. Controlla il sito da una rete esterna: se fallisce ovunque, passa ai controlli su certificato e server.
6. Confronta dominio principale e www: uno dei due nomi potrebbe non essere coperto o puntare a un server differente.

Soluzioni per chi visita il sito

1. Controlla data, ora e fuso orario

Il certificato contiene un intervallo di validità. Un dispositivo con data o ora errate può considerarlo scaduto o non ancora valido. Attiva la sincronizzazione automatica e verifica anche il fuso orario.

2. Aggiorna browser e sistema operativo

Un browser o un sistema molto vecchio può non supportare correttamente versioni TLS moderne, catene aggiornate o autorità di certificazione recenti. Installa gli aggiornamenti disponibili e riavvia il dispositivo.

3. Prova la navigazione in incognito

La modalità privata aiuta a escludere estensioni, cookie e dati temporanei. Se il sito funziona, riattiva le estensioni una alla volta per individuare quella che interferisce con HTTPS.

4. Cancella cache e cookie del dominio

Elimina inizialmente soltanto i dati del sito interessato. Questa operazione non corregge un certificato errato, ma può risolvere sessioni o redirect memorizzati in modo incoerente.

5. Disattiva temporaneamente VPN e proxy

VPN e proxy possono terminare e ricreare la connessione TLS. Disconnettili per una prova breve. Nelle reti aziendali non modificare configurazioni gestite senza l’autorizzazione dell’amministratore.

6. Verifica la scansione HTTPS dell’antivirus

Alcuni prodotti di sicurezza installano un certificato locale e analizzano il traffico cifrato. Una configurazione corrotta o non aggiornata può interrompere l’handshake. Disattiva la funzione soltanto per un test controllato, quindi riattivala immediatamente.

7. Riavvia router e dispositivo

Il riavvio chiude connessioni bloccate e può correggere problemi temporanei del router. Scollega il modem per circa trenta secondi, riaccendilo e attendi che la connessione sia stabile.

8. Prova un’altra rete

Usa temporaneamente la rete mobile. Se il sito torna raggiungibile, controlla DNS, proxy, firewall o filtri della rete originaria.

9. Non ignorare avvisi di sicurezza

Non inserire password, dati personali o informazioni di pagamento su un sito che presenta errori TLS. Evita soluzioni che disabilitano permanentemente i controlli del browser.

Controlli per il proprietario del sito

10. Verifica DNS A e AAAA

dig +short A esempio.it
dig +short AAAA esempio.it
dig +short A www.esempio.it
dig +short AAAA www.esempio.it

Controlla che tutti gli indirizzi puntino al server corretto. Un record AAAA dimenticato può inviare gli utenti IPv6 verso una macchina con certificato o virtual host non configurati.

11. Controlla la porta 443

nc -vz esempio.it 443
ss -lntp | grep ':443'

Il primo comando verifica la raggiungibilità dall’esterno; il secondo controlla se il server ascolta localmente. La porta aperta non garantisce però che il servizio risponda realmente con TLS.

12. Verifica dominio, scadenza e SAN del certificato

Il certificato deve essere valido e includere tutti gli hostname utilizzati, per esempio esempio.it e www.esempio.it. Il Common Name da solo non è sufficiente: i browser verificano i Subject Alternative Name.

13. Controlla la catena completa

Il server deve presentare il certificato del dominio insieme agli intermedi necessari. LiteSpeed documenta l’utilizzo di fullchain.pem e della configurazione della catena. Una catena incompleta può funzionare su alcuni dispositivi e fallire su altri.

14. Verifica che chiave privata e certificato corrispondano

Un certificato associato alla chiave sbagliata impedisce al server di completare correttamente TLS. Il controllo deve essere eseguito in modo sicuro sul server, senza copiare o condividere la chiave privata.

Per certificati RSA:

openssl x509 -noout -modulus -in certificato.pem | openssl sha256
openssl rsa  -noout -modulus -in chiave-privata.pem | openssl sha256

I due valori devono coincidere. Per chiavi di tipo differente utilizza i comandi OpenSSL appropriati. Non inviare mai il contenuto della chiave privata a servizi esterni.

15. Controlla SNI e virtual host

Su server che ospitano più domini, SNI permette di presentare il certificato corretto per ogni hostname. Se il virtual host HTTPS è assente o associato al certificato sbagliato, il browser può ricevere un certificato di un altro sito.

16. Controlla protocolli TLS e cifrari

Evita protocolli obsoleti. Allo stesso tempo, una configurazione eccessivamente restrittiva può escludere client ancora supportati. Verifica che il web server utilizzi versioni e cifrari coerenti con la tua compatibilità richiesta.

17. Esamina i log del web server

/usr/local/lsws/logs/error.log
/var/log/apache2/error.log
/var/log/httpd/error_log
/var/log/nginx/error.log

Cerca errori relativi a certificato, chiave, listener HTTPS, handshake, SNI e permessi dei file. Confronta sempre l’orario del test con il log.

Diagnosi con OpenSSL e curl

OpenSSL descrive s_client come un client generico SSL/TLS utile per diagnosticare i server. Il comando principale è:

openssl s_client -connect esempio.it:443 -servername esempio.it -showcerts

Controlla:

• certificato presentato;
• hostname e Subject Alternative Name;
• catena inviata;
• protocollo e cifrario negoziati;
• eventuali errori di verifica;
• presenza di una risposta TLS invece di semplice HTTP.

Per ottenere le date del certificato:

echo | openssl s_client \
  -connect esempio.it:443 \
  -servername esempio.it 2>/dev/null |
openssl x509 -noout -subject -issuer -dates

Per verificare la risposta con curl:

curl -Iv https://esempio.it/

curl -Iv mostra risoluzione DNS, connessione, negoziazione TLS e intestazioni. Non pubblicare output che contenga cookie, token o dati di autenticazione.

Per confrontare IPv4 e IPv6:

curl -4Iv https://esempio.it/
curl -6Iv https://esempio.it/

AutoSSL e cPanel

In cPanel, la sezione SSL/TLS Status consente di controllare quali domini sono protetti, quali certificati stanno per scadere e quali hostname non risultano coperti.

Controlla:

• che il dominio e il sottodominio www siano inclusi;
• che il dominio punti realmente al server;
• che non sia stato escluso da AutoSSL;
• che la verifica DCV sia riuscita;
• che eventuali record CAA consentano l’autorità di certificazione usata;
• che il certificato rinnovato sia installato sul virtual host corretto.

Da WHM puoi eseguire una verifica AutoSSL per tutti gli utenti:

/usr/local/cpanel/bin/autossl_check --all

Prima di rilanciare ripetutamente AutoSSL, consulta i log: il rinnovo può fallire per DNS errati, redirect della verifica, record CAA, limiti dell’autorità o hostname non raggiungibili.

LiteSpeed, Apache e Nginx

LiteSpeed

Verifica il listener HTTPS, il virtual host, il percorso del certificato, la chiave privata e l’opzione relativa al certificato concatenato. I file devono essere leggibili dal processo LiteSpeed. Dopo una modifica valida, utilizza un riavvio graceful anziché interrompere bruscamente il servizio.

Apache

Controlla il virtual host sulla porta 443, i percorsi del certificato e della chiave e la configurazione SNI. Prima di ricaricare il servizio, verifica la sintassi:

apachectl configtest

Nginx

Controlla i parametri listen 443 ssl, server_name, ssl_certificate e ssl_certificate_key. Verifica la sintassi prima del reload:

nginx -t

Non riavviare un server di produzione senza aver prima controllato configurazione, log e disponibilità di un rollback.

Cloudflare: errori 525 e 526

Cloudflare gestisce due connessioni TLS separate:

1. dal visitatore al nodo Cloudflare;
2. da Cloudflare al server di origine.

Errore 525: SSL handshake failed

Cloudflare indica che il 525 compare quando fallisce l’handshake tra Cloudflare e l’origine. Controlla:

• porta 443 raggiungibile;
• certificato installato sull’origine;
• SNI e virtual host;
• protocolli e cifrari supportati;
• firewall che potrebbe bloccare gli IP Cloudflare;
• stabilità e carico del server.

Errore 526: invalid SSL certificate

Il 526 indica che Cloudflare non riesce a verificare il certificato del server di origine. È particolarmente rilevante con la modalità Full (strict). Verifica scadenza, hostname, catena completa e autorità attendibile.

Modalità SSL/TLS

Per un sito pubblico è preferibile mantenere una connessione cifrata e verificata fino all’origine. Non utilizzare la modalità Flexible come scorciatoia per mascherare un certificato server non valido: può generare redirect e lasciare non cifrato il tratto tra Cloudflare e origine.

Dopo ogni modifica, controlla sia il certificato edge sia quello dell’origine. Se disattivi temporaneamente il proxy per una diagnosi, considera l’esposizione dell’IP reale e ripristina la configurazione prevista al termine del test.

ERR_SSL_PROTOCOL_ERROR su WordPress

WordPress è compatibile con HTTPS quando il certificato è installato e disponibile sul web server. L’errore di protocollo avviene normalmente prima che WordPress elabori la richiesta; tuttavia, configurazioni dell’applicazione possono aggravare il problema con redirect incoerenti.

Controlla:

• che Indirizzo WordPress e Indirizzo sito utilizzino il dominio corretto;
• che non esistano redirect duplicati tra plugin, .htaccess, web server e Cloudflare;
• che il sito non alterni continuamente HTTP e HTTPS;
• che il dominio principale e www siano entrambi coperti dal certificato;
• che la cache non conservi vecchi redirect;
• che proxy e CDN passino correttamente l’informazione sul protocollo HTTPS.

Il contenuto misto, da solo, di solito non produce ERR_SSL_PROTOCOL_ERROR: la pagina può aprirsi ma mostrare avvisi o risorse bloccate. Prima bisogna quindi risolvere handshake e certificato, poi correggere URL HTTP residui.

Per un’infrastruttura ottimizzata puoi consultare l’Hosting WordPress Xlogic, con LiteSpeed Enterprise, LSCache, CloudLinux, storage NVMe, Redis, backup JetBackup e protezione Imunify360.

Checklist finale

• Data, ora e fuso orario del dispositivo sono corretti?
• Browser e sistema operativo sono aggiornati?
• VPN, proxy e scansione HTTPS sono stati esclusi?
• Il problema si verifica da reti e dispositivi differenti?
• I record A e AAAA puntano al server corretto?
• La porta 443 è raggiungibile?
• Il server risponde realmente con TLS sulla porta 443?
• Il certificato è valido e non scaduto?
• Il certificato copre dominio e www?
• La catena completa viene inviata?
• Certificato e chiave privata corrispondono?
• SNI e virtual host sono configurati correttamente?
• Protocolli e cifrari sono compatibili?
• AutoSSL mostra errori DCV o hostname esclusi?
• I log del web server riportano errori SSL/TLS?
• La modalità Cloudflare è coerente con il certificato di origine?
• Cloudflare mostra un errore 525 o 526?
• WordPress o il server creano redirect HTTP/HTTPS duplicati?

Quando contattare il provider hosting

Contatta il provider quando non puoi gestire certificato, listener HTTPS, AutoSSL, firewall o configurazione del web server. Fornisci:

• dominio e hostname esatto che genera l’errore;
• data e ora del test;
• browser, sistema operativo e rete utilizzata;
• eventuale codice Cloudflare 525 o 526;
• output di curl -Iv e openssl s_client privato di dati sensibili;
• modifiche recenti a DNS, certificato, CDN o server.

Non inviare mai chiavi private, password, token, cookie o file di configurazione contenenti credenziali.

Domande frequenti su ERR_SSL_PROTOCOL_ERROR

Che cosa significa ERR_SSL_PROTOCOL_ERROR?

Significa che il browser non è riuscito a completare correttamente la connessione TLS con il sito oppure ha ricevuto una risposta non valida sulla porta HTTPS.

Il problema dipende sempre dal certificato?

No. Può dipendere anche da browser, data e ora, VPN, proxy, antivirus, porta 443, SNI, protocolli, cifrari, DNS o Cloudflare.

Come verifico se il certificato è scaduto?

Puoi controllarlo dal browser, da cPanel SSL/TLS Status oppure con OpenSSL visualizzando i campi notBefore e notAfter.

Perché il sito funziona su un dispositivo ma non su un altro?

I dispositivi possono avere sistemi, autorità attendibili, versioni TLS, proxy o antivirus differenti. Anche una catena incompleta può essere ricostruita da alcuni client ma non da altri.

Un record AAAA può causare l’errore?

Sì. Se IPv6 punta a un server non configurato correttamente per HTTPS, alcuni utenti possono ricevere l’errore mentre IPv4 continua a funzionare.

Che differenza c’è tra Cloudflare 525 e 526?

Il 525 indica il fallimento dell’handshake tra Cloudflare e origine; il 526 indica che Cloudflare non riesce a verificare il certificato dell’origine.

Posso usare Cloudflare Flexible per risolvere?

Non è una correzione del certificato dell’origine. Può causare redirect e non cifra il tratto tra Cloudflare e server. È preferibile configurare un certificato valido e usare Full (strict).

Il contenuto misto causa ERR_SSL_PROTOCOL_ERROR?

Normalmente no. Il contenuto misto viene gestito dopo l’apertura della connessione HTTPS. Può causare risorse bloccate o avvisi, ma non sostituisce una diagnosi dell’handshake.

Devo rigenerare subito il certificato?

Prima controlla DNS, hostname coperti, scadenza, catena, chiave e virtual host. Rigenerare senza individuare la causa può produrre lo stesso errore o raggiungere limiti dell’autorità.

OpenSSL s_client modifica il server?

No. Il comando apre una connessione diagnostica e mostra i dettagli TLS. Non modifica certificati o configurazioni.

Conclusione

ERR_SSL_PROTOCOL_ERROR richiede un’analisi ordinata: prima si escludono dispositivo e rete, poi si controllano DNS e porta 443, infine certificato, catena, chiave, SNI, protocolli, web server e CDN.

La soluzione corretta non consiste nel disabilitare i controlli di sicurezza, ma nel ripristinare una configurazione HTTPS valida e verificabile. Per siti professionali consulta l’Hosting Condiviso Xlogic, l’Hosting WordPress Xlogic oppure il servizio per cambiare hosting.

Fonti ufficiali e approfondimenti

• Cloudflare: troubleshooting ERR_SSL_PROTOCOL_ERROR
• Cloudflare: errore 525
• Cloudflare: errore 526
• OpenSSL: s_client
• cPanel: Manage AutoSSL
• cPanel: SSL/TLS Status
• LiteSpeed Web Server: configurazione SSL
• WordPress: HTTPS