ERR_SSL_PROTOCOL_ERROR: what it means and how to fix it

ERR_SSL_PROTOCOL_ERROR means the browser and the server failed to set up an encrypted connection, before any certificate was checked. It is the least specific SSL code in Chrome and Edge, so the fix depends on finding where the setup broke: on the visitor's side, in the network, or in the server's configuration. One test, trying another network, settles most of that in a minute.

Quick facts

Browsers

Chrome, Edge and other Chromium browsers

Exact text

This site can't provide a secure connection with ERR_SSL_PROTOCOL_ERROR

What failed

the TLS handshake, before certificate validation

Who fixes it

either side; elimination is the only way to tell

Firefox equivalents

SSL_ERROR_RX_RECORD_TOO_LONG, PR_END_OF_FILE_ERROR

What the error means

An HTTPS connection starts with a TLS handshake: the browser proposes protocol versions and ciphers, the server picks from them, and only then does the server present its certificate. This error means the exchange broke during that first part. The server answered with something the browser could not read as TLS, closed the connection, or sent nothing usable.

Because the failure happens so early, the browser has little to report. That is the difference from Your connection is not private, which appears when the handshake worked and the certificate failed a check. For that case, see Your connection is not private. One of those checks is the issuer: a certificate the browser cannot trace to a trusted authority is reported as ERR_CERT_AUTHORITY_INVALID.

Fixes for visitors

Start here if the site is someone else's. These causes affect one device or one network, and each check takes under a minute.

• Try another network. Use mobile data instead of Wi-Fi, or the reverse. If the site works there, the first network is interfering: a corporate proxy, a filtering appliance, or a public Wi-Fi login page that has not let you through yet. Opening any plain website usually brings up the login page.

• Check the date and time. A clock that is far off can break the handshake as well as the certificate check. Set it to update automatically.

• Turn off HTTPS scanning for a moment. Antivirus products and some VPNs intercept encrypted connections. When they cannot agree on settings with the server, this error is the result. If turning the feature off fixes the site, keep it off for that site or update the product.

• Try a private window or another browser. Extensions and stored browser state occasionally cause the error in one browser only. Clearing the browser's cache and the operating system's SSL state is the last thing to try, not the first.

If the site fails on a second network and a second device, the problem is at the site.

Fixes for site owners

These causes affect every visitor, or every visitor with a particular browser. Check them in this order.

• Plain HTTP is answering on port 443. The most common server-side cause. The server or a proxy in front of it listens on the HTTPS port without TLS enabled, so the browser receives a plain HTTP response where it expected a handshake. Firefox reports this one precisely, as SSL_ERROR_RX_RECORD_TOO_LONG. In nginx, the listen 443 line needs the ssl parameter; in Apache, the virtual host on port 443 needs SSLEngine on. See port 443.

• No shared protocol version. The server offers only versions that current browsers have removed, such as TLS 1.0 and 1.1, or a client is too old for what the server offers. A server today should accept TLS 1.2 and TLS 1.3. How to check and set them is on TLS versions.

• No shared cipher. Both sides support a common version but no common cipher suite. Chrome usually reports this as ERR_SSL_VERSION_OR_CIPHER_MISMATCH, but it can surface as a protocol error depending on where the negotiation stops.

• No configuration for this hostname. When several sites share one IP address, the server chooses which certificate and settings to use from the name the browser sends, called SNI. If no configuration matches that name and there is no usable default, the server may close the connection instead of completing the handshake.

• A proxy or CDN in front of the server. If TLS ends at a load balancer or CDN, that layer's configuration is what browsers see. A correct server behind a misconfigured front layer still produces this error.

How to diagnose

Test from outside the server, against the hostname visitors use:

$ curl -v https://example.com/
$ openssl s_client -connect example.com:443 -servername example.com </dev/null

Curl's verbose output shows how far the handshake went. A wrong version number error from either command means the port answered with something that is not TLS, usually plain HTTP. A connection that closes with no response points at the server or something in front of it refusing the handshake. If the handshake completes here and browsers still fail, compare protocol versions with the commands on TLS versions.

The command-line equivalent of this error is a handshake failure, covered on SSL handshake failed.

How to prevent it

Check the handshake from outside after every change to the server, proxy or CDN configuration, not only after certificate changes. A configuration file shows what was intended; a test against the public hostname shows what is served.

Review the protocol versions the server accepts once in a while. Browsers remove old versions on their own schedule, so a server that worked for years can start failing without any change on its side.

FAQ