How to fix ERR_SSL_PROTOCOL_ERROR

Firefox shows SSL_ERROR_RX_RECORD_TOO_LONG or Secure Connection Failed for the same problems.

If you are visiting the site

1. Check the date and time on your device. Turn on automatic time.
2. Try a private window, which skips extensions and cached data.
3. Try another network. Some office, school and public networks, and some antivirus software, inspect HTTPS traffic and break the handshake. If the site works on mobile data, that is the cause.
4. Update your browser. Very old browsers cannot use the TLS versions modern servers require.

If it fails on every device and network, only the site owner can fix it.

If you run the site

1. Test the handshake

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

openssl says	Meaning	Go to
wrong version number	Port 443 is answering with plain HTTP	Step 2
no peer certificate available	No certificate configured for that name	Step 3
unexpected eof while reading or sslv3 alert handshake failure	No protocol or cipher both sides accept, or the server closed the connection	Steps 4 and 5
Connection refused	Nothing listening on 443	ERR_CONNECTION_REFUSED
A certificate and Verify return code: 0 (ok)	The server is fine; look at the visitor’s network or a CDN	Step 6

You can also see the plain-HTTP problem directly: curl -v http://example.com:443/ returning a normal HTML page means HTTP is being served on the HTTPS port.

2. Plain HTTP on the HTTPS port

In Nginx, an HTTPS site needs ssl on its listen line:

listen 443 ssl;
listen [::]:443 ssl;
http2 on;

listen 443; without ssl serves plain HTTP on the HTTPS port, which causes exactly this error. Check every site on the server, because one server block with the mistake can affect the others:

grep -Rn "listen.*443" /etc/nginx/
sudo nginx -t && sudo systemctl reload nginx

On Apache, the HTTPS virtual host needs SSLEngine on and the SSL module enabled: sudo a2enmod ssl && sudo systemctl reload apache2.

3. No certificate for the name

If no site on the server has a certificate for the requested name, Nginx falls back to its default server, which may have none, and the handshake fails. Issue a certificate with every name visitors use:

sudo certbot --nginx -d example.com -d www.example.com

See how to get a free SSL certificate with Let’s Encrypt. Also check the files the configuration names actually exist and are readable:

sudo ls -l /etc/letsencrypt/live/example.com/

4. Outdated or over-strict TLS settings

Allow the two current versions:

ssl_protocols TLSv1.2 TLSv1.3;

A configuration that only allows TLS 1.0 or 1.1, or a cipher list copied from an old guide, can leave nothing a modern browser accepts. The reverse also happens: a list so strict that older phones and browsers cannot connect. Certbot’s own settings file, included with include /etc/letsencrypt/options-ssl-nginx.conf;, is a sensible default. Mozilla’s SSL Configuration Generator produces current settings for every common server.

5. Old software on the server

Very old OpenSSL versions cannot speak TLS 1.3 or modern ciphers. Check:

openssl version
nginx -V 2>&1 | grep -o "OpenSSL [0-9.]*"

A version older than 1.1.1 means the operating system is out of support; upgrading it is the real fix.

6. Behind Cloudflare or another CDN

Visitors connect to the CDN, so the CDN’s settings decide the handshake. In Cloudflare, check SSL/TLS > Edge Certificates: the certificate must be active for your domain, and newly added domains can take a few minutes. A Minimum TLS Version set too high blocks older devices. If a subdomain is more than one level deep, such as a.b.example.com, Cloudflare’s free certificate does not cover it.

Confirm it is fixed

Run the openssl command from step 1 again: you want a certificate chain and Verify return code: 0 (ok). Then load the site in a private window on a phone using mobile data.

Related

• “Your connection is not private”.
• How HTTPS works.
• What a port number is.