ERR_SSL_PROTOCOL_ERROR: What It Means and How to Fix It

The most useful thing to know about this error is what it is not.

It is not a certificate problem. Expired certificates, name mismatches and untrusted issuers all produce a different family of errors — the ones beginning NET::ERR_CERT_ — and every one of those means the connection got far enough for the browser to examine a certificate and reject it.

ERR_SSL_PROTOCOL_ERROR means it never got that far. The two sides could not agree on how to speak TLS at all, so no certificate was ever evaluated.

That single distinction eliminates most of what people try first. Reissuing the certificate will not help, because the certificate was never the problem.

Where you will see it

Chrome and Edge:

This site can't provide a secure connection
example.com sent an invalid response.
ERR_SSL_PROTOCOL_ERROR

Firefox words the same failure differently:

Secure Connection Failed
SSL_ERROR_RX_RECORD_TOO_LONG

curl:

curl: (35) error:0A00010B:SSL routines::wrong version number

Those last two are worth memorising. wrong version number and SSL_ERROR_RX_RECORD_TOO_LONG almost always mean one specific thing, and it is the first cause below.

What actually causes it

The server is not speaking TLS on that port

The most common cause, and the easiest to miss.

If a server is configured to serve plain HTTP on port 443, the browser opens a TLS handshake and receives an HTTP response instead. It has no idea what to do with that, so it reports a protocol error.

That is exactly what wrong version number is telling you: the bytes that came back were not TLS at all.

Typical when a virtual host was set up on 443 without SSL enabled, when a reverse proxy forwards to a backend expecting HTTP, or when a site has just moved and the SSL configuration did not come with it.

TLS version mismatch

Browsers removed support for TLS 1.0 and 1.1 in 2020. A server that still offers only those protocols can no longer negotiate with any current browser.

The symptom is distinctive: the site works in an old browser, on an old phone, or from a tool that still permits legacy protocols, and fails everywhere modern. Nothing on the server changed — the browsers did.

The same happens in reverse on hardened servers configured for TLS 1.3 only, when something old tries to connect.

No shared cipher suite

The two sides support overlapping TLS versions but no common cipher. Chrome has its own error for this — ERR_SSL_VERSION_OR_CIPHER_MISMATCH — but a protocol error can surface for the same underlying reason depending on where negotiation breaks.

Usually a server configured with a restrictive cipher list, often copied from a hardening guide written years earlier.

Something is intercepting the connection

Antivirus products with HTTPS scanning, corporate proxies and some VPN clients insert themselves into TLS connections by design. When that interception is misconfigured or outdated, the result is a protocol error.

The giveaway: the site fails on one machine and works on every other device on the same network.

How to diagnose it

1. Try another device on the same network

Works elsewhere → the problem is on that one machine. Antivirus, a browser extension, or the browser's own TLS state.

Fails everywhere → the problem is the server.

Thirty seconds, and it splits the problem in half. Do it first.

2. Ask the server directly what it supports

openssl s_client -connect example.com:443 -servername example.com

Read the reply:

• wrong version number → the server is not serving TLS on 443
• A handshake that completes, showing a protocol and cipher → the server is fine and your client is the problem
• no protocols available or an immediate close → version or cipher mismatch

3. Pin down which TLS versions work

openssl s_client -tls1_2 -connect example.com:443 -servername example.com
openssl s_client -tls1_3 -connect example.com:443 -servername example.com

If 1.2 fails and 1.3 succeeds — or the reverse — you have found the mismatch, and the fix is in the server's protocol configuration.

4. Confirm the port is actually open

If nothing answers at all, you do not have a TLS problem — you have a connectivity problem wearing a TLS error.

How to fix it

If it is only your machine:

• Disable HTTPS scanning in your antivirus temporarily and retest
• Try an incognito window to rule out extensions
• Clear the browser's SSL state — chrome://net-internals/#hsts can hold stale entries for a specific domain
• Test in a different browser. Chrome failing where Firefox works points at Chrome's own state

If it is the server:

• Confirm SSL is actually enabled on the listening block for 443 — this resolves the wrong version number case outright
• Enable TLS 1.2 alongside 1.3. Serving only 1.3 excludes a meaningful share of clients; serving only 1.0 or 1.1 excludes every current browser
• Review the cipher list, especially if it was copied from an old hardening guide
• Verify the certificate and private key are a matching pair, and that the configuration was actually reloaded

How it differs from the other SSL errors

ERR_SSL_PROTOCOL_ERROR — the handshake failed. No certificate was examined.

NET::ERR_CERT_DATE_INVALID, ERR_CERT_AUTHORITY_INVALID, ERR_CERT_COMMON_NAME_INVALID — the handshake succeeded and a certificate was presented, then rejected.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH — same family as a protocol error, but Chrome has identified the specific reason. Treat it as a protocol error with a head start.

ERR_CONNECTION_RESET on port 443 — not TLS at all. Something closed the TCP connection before TLS began, usually a firewall.

The practical rule: a CERT error is about the certificate. Everything else is about whether a TLS conversation could happen in the first place.

One thing worth knowing

An expired certificate does not cause this. That produces NET::ERR_CERT_DATE_INVALID, and the browser offers a bypass option.

A protocol error has no bypass — there is nothing to bypass, because no secure channel was ever established.

The short version

Test another device first: if the site works there, the fault is on your machine, usually antivirus HTTPS scanning. If it fails everywhere, run openssl s_client — wrong version number means the server is serving plain HTTP on 443, and a handshake that completes means the server is fine and your client is not.

If you want to check what a server is actually presenting from outside your own network — chain, covered names, expiry — I keep a free checker at webtoolsrealm.com/tool/ssl-checker. Full disclosure, that's my own site.

Originally published at webtoolsrealm.com