Cart 0

No products in the cart.

Account

SSL errors

ERR_SSL_PROTOCOL_ERROR: What It Means and How to Fix It

ERR_SSL_PROTOCOL_ERROR means the browser and server could not agree on how to set up a secure connection. Here is how to find the cause and fix it on either side.

4 min read

ERR_SSL_PROTOCOL_ERROR means the secure connection failed during the TLS handshake, the first exchange in which browser and server agree on a protocol version and encryption settings. The cause is usually a server setting, such as outdated TLS versions or a broken virtual host, or something on the network that interferes. Your SSL certificate is rarely the problem.

What causes ERR_SSL_PROTOCOL_ERROR?

The browser and server could not complete the TLS handshake. Most often the server offers only old protocol versions or cipher suites (sets of encryption algorithms) the browser no longer accepts, the server is misconfigured, or a middlebox such as a firewall, proxy or antivirus program breaks the connection.

CauseWhere it sitsTypical sign
Server offers only TLS 1.0 or 1.1ServerFails in every current browser, works in old tools
No cipher suite in commonServerFails after a hardening change or an OS upgrade
Port 443 answers with plain HTTPServerFails right after setup or a config edit
No certificate configured for this hostname (SNI)ServerOne domain on a shared server fails, others work
Firewall, proxy or antivirus inspecting HTTPSNetwork or deviceFails only in one office, network or computer
QUIC, extension or cached data in the browserBrowserFails in one browser, works in another

Check your server in seconds

Our checker shows which certificate and chain your server sends for a hostname, so you can rule out the certificate side first.

Run the SSL checker

Is my certificate the problem?

Usually not. This error appears when the handshake fails before the browser has finished checking the certificate, so the cause is almost always the server or network configuration. Problems with the certificate itself, such as an expired date or a wrong name, show their own codes like NET::ERR_CERT_DATE_INVALID.

There are exceptions. If the certificate file, private key or chain is missing or does not match, some servers start the HTTPS listener without a usable certificate and break every handshake. Our SSL checker quickly shows whether the certificate side is fine. The overview of SSL certificate errors lists the certificate-specific warnings.

Narrow it down before you change anything

  1. Test another browser and network

    If the site works on a phone using mobile data, the problem is local to the first device or network.

  2. Check the certificate side

    Confirm a valid certificate and complete chain are served for the exact hostname.

  3. Test the handshake directly

    Use openssl s_client from a server or terminal to see which TLS versions the site accepts.

  4. Fix the side that fails

    Server issue: follow the server steps below. Device issue: follow the browser steps.

How do I fix it on my server?

Enable TLS 1.2 and TLS 1.3, offer modern cipher suites, and make sure every hostname has its own HTTPS virtual host with a certificate. Then reload the server and test again from outside your network.

1. Enable TLS 1.2 and TLS 1.3

Chrome removed support for TLS 1.0 and 1.1 in Chrome 84 (2020), and other current browsers have done the same. A server that still offers only those versions produces this error. The basic settings look like this:

  • Nginx: ssl_protocols TLSv1.2 TLSv1.3; in the server block
  • Apache: SSLProtocol -all +TLSv1.2 +TLSv1.3 in the SSL virtual host
  • IIS: enable TLS 1.2 (and TLS 1.3 where Windows Server supports it) in the Windows SChannel settings, then restart

For the differences between the two versions and how to switch TLS 1.3 on, see TLS 1.2 vs TLS 1.3.

2. Offer current cipher suites

If you hand-picked a cipher list years ago, it may contain only algorithms that browsers have dropped. Use your server’s current recommended defaults, or a list built for TLS 1.2 and 1.3 with ECDHE key exchange and AES-GCM or ChaCha20.

3. Check SNI and virtual hosts

SNI (Server Name Indication) lets one IP address serve different certificates for different hostnames. If a hostname has no HTTPS virtual host, the server may answer with the wrong configuration or none at all. Confirm that port 443 is set up for TLS (for example listen 443 ssl; in Nginx) and that each domain has a certificate assigned. If you need to redo this, follow our guide to install an SSL certificate.

Tip: Test the handshake with openssl s_client -connect example.com:443 -servername example.com -tls1_2, then repeat with -tls1_3. A failure on both points to the server, not the browser.

How do I fix it in my browser?

If the site works elsewhere, reset the parts of your browser and device that touch encrypted connections. Test one change at a time so you know what fixed it.In a company network, ask IT whether a proxy or firewall inspects HTTPS traffic – that is a common cause they need to fix centrally.

  • Open a private window to rule out extensions, then disable them one by one
  • Temporarily turn off QUIC in chrome://flags and restart the browser
  • Pause your antivirus HTTPS or "web shield" scanning to test
  • Check that date, time and time zone are set automatically
  • Clear the browser cache and cookies for the site
  • Update the browser and operating system
  • Try another network to rule out a proxy or firewall

Quick diagnosis table

What you observeMost likely causeNext step
Every browser and device failsServer protocol, cipher or listener settingEnable TLS 1.2/1.3 and check port 443 config
Only one domain on the server failsMissing HTTPS virtual host or SNI mappingAdd the host and assign its certificate
Only one computer failsAntivirus, extension, QUIC or clockWork through the browser checklist
Only one office network failsProxy or firewall doing HTTPS inspectionAsk IT to update or bypass the inspection

Confirm the fix

After changing the server, check the hostname again to make sure the right certificate and chain are served.

Check your site now

Related articles

Frequently asked questions

Q: What causes ERR_SSL_PROTOCOL_ERROR?

A: The TLS handshake between browser and server failed. Common causes are a server that only offers TLS 1.0 or 1.1, no cipher suite both sides support, a port 443 that answers with plain HTTP, or a missing HTTPS virtual host for the hostname. Middleboxes such as firewalls, proxies or antivirus HTTPS scanning can also break the handshake on specific networks or devices.

Q: How do I fix it on my server?

A: Enable TLS 1.2 and TLS 1.3 and disable older versions, then use current recommended cipher suites. Make sure port 443 is configured for TLS and that every hostname has its own HTTPS virtual host with a certificate, which relies on SNI. Reload the server and test with openssl s_client or an SSL checker from outside your network to confirm the handshake now succeeds.

Q: How do I fix it in my browser?

A: First test the site in a private window and on another device. If only your browser fails, disable extensions one by one, temporarily turn off QUIC in chrome://flags, and pause antivirus HTTPS scanning to see if it interferes. Also check the system clock, clear the cache for the site, update the browser, and try another network to rule out a proxy.

Q: Is my certificate the problem?

A: Usually not. ERR_SSL_PROTOCOL_ERROR comes from a failed handshake, which is a configuration or network issue. Certificate problems such as expiry or a wrong domain name trigger their own error codes. The exception is a missing or mismatched certificate, private key or chain in the server configuration, which can stop the HTTPS listener from working. An SSL checker quickly shows whether the certificate side is fine.