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.
Risposta rapida: controlla data e ora del dispositivo, aggiorna il browser, prova un’altra rete e disattiva temporaneamente VPN, proxy o scansione HTTPS dell’antivirus. Se gestisci il sito, verifica certificato, dominio coperto, data di scadenza, catena completa, chiave privata, porta 443, configurazione SNI, web server, AutoSSL cPanel e modalità SSL/TLS di Cloudflare.
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
| Errore | Significato principale | Controllo prioritario |
|---|---|---|
| ERR_SSL_PROTOCOL_ERROR | L’handshake TLS non viene completato o la risposta sulla porta HTTPS non è valida. | Protocollo, certificato, catena, porta 443, proxy e server. |
| NET::ERR_CERT_DATE_INVALID | Il certificato risulta scaduto, non ancora valido oppure il dispositivo ha data e ora errate. | Validità del certificato e orologio del dispositivo. |
| NET::ERR_CERT_COMMON_NAME_INVALID | Il certificato non copre il nome host richiesto. | SAN del certificato, dominio e virtual host. |
| ERR_SSL_VERSION_OR_CIPHER_MISMATCH | Client e server non trovano una versione TLS o un cifrario compatibile. | Versioni TLS, cifrari e copertura del certificato CDN. |
| Cloudflare 525 | Fallisce l’handshake TLS tra Cloudflare e il server di origine. | Certificato e configurazione HTTPS dell’origine. |
| Cloudflare 526 | Cloudflare non riesce a verificare il certificato dell’origine. | Validità, hostname e catena del certificato in modalità Full (strict). |
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:
- Apri altri siti HTTPS: se falliscono tutti, controlla dispositivo, rete, antivirus, proxy o data e ora.
- Prova un altro browser: se il sito funziona, il problema può riguardare cache, estensioni o configurazione del browser.
- Usa un altro dispositivo sulla stessa rete: se fallisce anche quello, verifica router, DNS o filtri di rete.
- Prova la rete mobile: se il sito funziona, il problema potrebbe dipendere dal Wi-Fi, dal provider o da un proxy locale.
- Controlla il sito da una rete esterna: se fallisce ovunque, passa ai controlli su certificato e server.
- Confronta dominio principale e www: uno dei due nomi potrebbe non essere coperto o puntare a un server differente.
| Risultato | Causa probabile |
|---|---|
| L’errore compare su molti siti | Orologio, browser, sistema, antivirus, VPN, proxy o rete locale. |
| L’errore compare soltanto su un sito | Certificato, DNS, web server, CDN o virtual host del dominio. |
| Funziona da rete mobile ma non dal Wi-Fi | Proxy, DNS, filtro di rete, router o ispezione HTTPS. |
| Funziona senza Cloudflare | Modalità SSL/TLS, certificato edge/origin o firewall dell’origine. |
| Funziona su IPv4 ma non su IPv6 | Record AAAA o configurazione HTTPS del server IPv6. |
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.itControlla 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 sha256I 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.logCerca 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 -showcertsControlla:
- 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 -datesPer 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 --allPrima 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 configtestNginx
Controlla i parametri listen 443 ssl, server_name, ssl_certificate e ssl_certificate_key. Verifica la sintassi prima del reload:
nginx -tNon 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:
- dal visitatore al nodo Cloudflare;
- 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 -Iveopenssl s_clientprivato 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.
