ERR_SSL_PROTOCOL_ERROR: Causes and Fixes
By the Does This Really Work Or Not editorial team
Published: October 6, 2026 · Last reviewed: October 6, 2026
Quick answer: ERR_SSL_PROTOCOL_ERROR ("This site can't provide a secure connection") means your browser and the website couldn't finish the TLS handshake, the step where they agree how to encrypt the connection. Nothing has been loaded yet. The cause is either the server's HTTPS setup or something on your device that interferes with secure connections, such as the clock, antivirus or a proxy.
Is it you or the website? A one-minute check
- Open the site in a different browser and on a different network, for example your phone on mobile data.
- It fails everywhere: the problem is almost certainly the website. Go to If it's your website.
- It fails only on one device or network: the problem is local. Go to If you're visiting the site.
- Run the domain through our SSL checker. It uses Qualys SSL Labs to test the server from outside your network. If the scan can't complete a secure connection either, the server is at fault.
What's actually going wrong
Before any page loads over HTTPS, the browser and server exchange "hello" messages. They agree a protocol version (TLS 1.2 or 1.3 today), pick an encryption method, and the server presents its certificate. ERR_SSL_PROTOCOL_ERROR is Chrome's general-purpose message for "that exchange broke". It's vaguer than most SSL errors, which is why it has so many possible causes.
More specific errors point to narrower problems:
ERR_SSL_VERSION_OR_CIPHER_MISMATCH: the two sides share no protocol version or encryption method. Typically the server only offers TLS 1.0 or 1.1, which modern browsers stopped accepting around 2020.NET::ERR_CERT_*errors: the connection worked, but the certificate failed a check, for example by being expired. See NET::ERR_CERT_DATE_INVALID.
If you're visiting the site
- Check your device's date and time. Turn on automatic time. A clock that is far off breaks certificate and handshake checks.
- Try an Incognito/Private window. If the site works there, a browser extension is interfering. Disable extensions one at a time to find which.
- Turn off antivirus "HTTPS scanning" or "web shield" for a moment. Some security software intercepts encrypted connections, and an outdated version can break the handshake. If that fixes it, update the software rather than leaving protection off.
- Disable any VPN, proxy or company network filter and test again.
- Clear the browser's cached data for that site. In Chrome: Settings → Privacy and security → Delete browsing data → Cached images and files.
- On Windows, clear the SSL state: search for "Internet Options" → Content tab → Clear SSL state.
- Update your browser and operating system. Very old systems may not support the TLS versions modern servers require.
If the site works from other networks but never from yours, a firewall or filter on your network is breaking secure connections. Its administrator has to fix that.
If it's your website
- Confirm HTTPS is actually served on port 443. A very common cause is a web server listening on port 443 but answering with plain HTTP, after a config typo or a missing
ssldirective. In Nginx that'slisten 443 ssl;, plus thessl_certificateandssl_certificate_keylines. - Check the certificate covers the exact hostname. If the server hosts several sites, the browser sends the hostname during the handshake, a feature called SNI. A missing or wrong server block for that name can break the handshake or present the wrong certificate.
- Enable TLS 1.2 and TLS 1.3, and disable 1.0 and 1.1.
- Nginx:
ssl_protocols TLSv1.2 TLSv1.3; - Apache:
SSLProtocol -all +TLSv1.2 +TLSv1.3
- Nginx:
- If you use Cloudflare or another CDN, check the SSL/TLS encryption mode.
- "Full" or "Full (strict)": the origin server must have a working certificate.
- "Flexible": the CDN connects to the origin over plain HTTP, which can loop or fail if the origin also forces HTTPS.
- Newly added domains: the CDN's edge certificate can take a while to be issued.
- Check the server's error log right after a failed attempt. Lines such as "SSL_do_handshake() failed" or "no shared cipher" name the cause.
- Re-run our SSL checker after each change. It shows which protocol versions the server accepts and when the certificate expires.
FAQ
Is ERR_SSL_PROTOCOL_ERROR dangerous?
No. No data was exchanged, because the connection never completed. It's a failure, not an attack warning. Don't bypass it by switching to http:// if you're entering passwords or payment details.
Why does it happen only on one Wi-Fi network?
Some routers, hotel networks and company firewalls inspect or block encrypted traffic, and old ones break modern TLS. Mobile data or a different network usually confirms it.
Can clearing cookies fix it?
Rarely. The handshake happens before cookies are sent. Clearing cached files and the SSL state, as in steps 5 and 6 above, helps more often.