ERR_SSL_PROTOCOL_ERROR (Chrome)

Where you see it

As a grey error page in Chrome, Edge and other Chromium browsers. The code is ERR_SSL_PROTOCOL_ERROR (−107, “An SSL protocol error occurred”) in Chromium’s network error list.

This site can’t provide a secure connection
www.example.com sent an invalid response.
Try running Windows Network Diagnostics.
ERR_SSL_PROTOCOL_ERROR

Edge shows the same code under the heading “The connection for this site is not secure”. There is no Advanced button and no way to continue, because the browser never got as far as checking a certificate. Firefox reports the most common cause below as SSL_ERROR_RX_RECORD_TOO_LONG.

What it means

Before a secure page loads, the browser and the server run a TLS handshake. They agree on a TLS version and a cipher suite, and the server proves who it is with its certificate. Chrome shows this code when the handshake breaks in a way it has no more specific error for: the reply was not valid TLS, or the other side ended the handshake with an alert that has no more specific error. In Chromium’s source it is the fallback for TLS errors that are not mapped to anything else (openssl_ssl_util.cc). The certificate itself is rarely the problem.

Likely causes

The server speaks plain HTTP on the HTTPS port

This is the most common cause when you run the server. Chrome sends a TLS “ClientHello” and gets an ordinary HTTP answer back. Typical reasons:

nginx with listen 443; but without the ssl parameter;
a load balancer or port forward that sends port 443 to the application’s HTTP port;
a container port mapping that points at the wrong port inside the container.

Confirm with OpenSSL. A plain-HTTP answer looks like this:

openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null

CONNECTED(00000003)
40F718D7C77E0000:error:0A00010B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:354:

Most OpenSSL releases from 3.2 on word the same thing as packet length too long, followed by record layer failure; the patch releases 3.3.7, 3.4.5, 3.5.6 and 3.6.2, and 4.0 and later, say wrong version number again. A plain request to the same port, curl -v http://www.example.com:443/, then gets an HTTP response.

Fix: turn on TLS for that listener. In nginx:

server {
    listen 443 ssl;
    server_name www.example.com;
    ssl_certificate     /etc/ssl/www.example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/www.example.com/privkey.pem;
}

On a load balancer, either point the HTTPS listener at a port where the application speaks TLS, or end TLS on the load balancer and forward to the HTTP port. See How to install a certificate in nginx.

Something between you and the server interferes

Antivirus products that scan HTTPS, TLS-inspection proxies, captive portals on public Wi-Fi and some firewalls sit in the middle of the connection. If one of them cuts the handshake short or answers with its own block page, Chrome sees an invalid response. The signs: many HTTPS sites fail on one network or one computer, and the same sites work elsewhere.

Confirm by trying another network, and check who issued the certificate you receive for a well-known public site:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -issuer

If the issuer is a security product rather than a public CA, the traffic is being inspected.

Fix: ask IT to repair the proxy or exempt the site, or update the antivirus product or switch off its HTTPS scanning. See How to work behind a TLS-inspecting corporate proxy, safely.

The server ends the handshake

A server, load balancer or appliance with a broken TLS setup can also stop the handshake halfway with a fatal alert. (One that simply closes the connection shows up as ERR_CONNECTION_CLOSED or ERR_CONNECTION_RESET instead.) Chromium reports a handshake_failure alert that arrives after its first message as this code. The same alert straight after the ClientHello means “nothing in common” and becomes ERR_SSL_VERSION_OR_CIPHER_MISMATCH instead.

Confirm with the openssl s_client command above and read its last error line: it names the alert the server sent, for example alert handshake failure. Then look in the server’s error log at the time of the failed request.

Fix: correct the server’s TLS settings, and compare them with a known-good configuration in How to configure TLS securely.

Check yours

Try it: Paste your errorOpen the full tool

Runs in your browser. Nothing you paste is sent anywhere.

Paste your error message

Try an example

The whole message or just the important line. A stack trace is fine; we look for the known parts.

Or browse all error pages by tool.

Paste the full error text, or the last lines of the openssl s_client output. The finder shows the matching page, so you can tell a protocol problem from a certificate problem.

Learn why

The TLS 1.3 handshake: what the first messages carry, and where a handshake can fail.
The same kind of failure in other tools: curl: (35) and Python’s WRONG_VERSION_NUMBER.

In the gameLevel 15: The handshakeThe Barbican, Keystone. In development