SSL_ERROR_RX_RECORD_TOO_LONG in Firefox: What It Means and the Fix

SSL_ERROR_RX_RECORD_TOO_LONG: what it means

With https, the browser opens the conversation with an encrypted "handshake" (the TLS handshake) and expects a reply in the same "language". When the server isn't configured for https on that port, it replies with plain http text, something like "HTTP/1.1 400 Bad Request". Firefox tries to read that text as a TLS packet, the "length" it gets is absurdly large, and it stops, saying it received a record longer than allowed.

Put simply: you knocked on the https door and someone who only speaks http answered. It doesn't mean the site was hacked; it is a configuration problem.

How it looks in Chrome, Edge, Firefox and Safari

Chrome's code also covers other causes (computer clock, antivirus and more); see the ERR_SSL_PROTOCOL_ERROR guide.

If you are a visitor

1. Check the address. If there is a port after the name (e.g. https://company.com:80 or :8080), remove it and try again.
2. Try another network or device. If the error appears everywhere, the server is at fault: let the site owner know.
3. If it only happens to you, check proxy, VPN and antivirus. A proxy set up wrongly in Firefox's network settings, or software that "scans" https, can answer with http where https is expected.
4. Don't look for a "continue" button. This is not a certificate warning you can click past; the secure connection simply wasn't set up.

If you own the website: the usual causes

1. SSL isn't enabled on port 443. The server listens on 443 but without encryption. In Apache this happens when the <VirtualHost *:443> block lacks SSLEngine on and the certificate lines. In Nginx, when you write listen 443; instead of listen 443 ssl;. Add the SSL settings and restart the service.
2. The certificate hasn't been issued or activated yet. In some setups, until the certificate is issued and applied, port 443 doesn't serve proper https. Open your hosting control panel, check that SSL is enabled for this exact domain and issue (or re-issue) the free certificate.
3. Wrong port in the address or links. https://company.com:80 or https://company.com:8080 sends encrypted traffic to a port that speaks plain http. Check redirects, the site address in your CMS settings and any links that include a port.
4. Proxy, load balancer or port forwarding to http. If a reverse proxy or load balancer passes port 443 traffic untouched to a backend that only speaks http, or your router forwards external 443 to internal 80 (common with NAS boxes and cameras), you get this error. Either the proxy "unlocks" TLS and talks http to the backend, or the backend must listen for https.

PR_END_OF_FILE_ERROR: the related case

Under the same "Secure Connection Failed" title, Firefox sometimes shows the code PR_END_OF_FILE_ERROR. Here the connection was closed abruptly in the middle of the handshake, with no reply at all. Usually something between you and the site is to blame: a proxy, VPN or antivirus that "scans" https connections. Try without them and from another network. If the error appears everywhere, the server or a firewall in front of it is closing the connection and the owner needs to look at it.

Confirm that port 443 doesn't speak https

More: ERR_SSL_VERSION_OR_CIPHER_MISMATCH, free SSL with Let's Encrypt and Chrome's "Not secure" warning.

Common mistakes

• Renewing or buying a certificate when the real problem is that SSL isn't even enabled on port 443.
• Adding an http to https redirect before https works: you send every visitor straight to the error.
• Testing in one browser only: in Chrome the same problem is called ERR_SSL_PROTOCOL_ERROR and you may think it is a different issue.
• Forgetting that behind Cloudflare the SSL Checker sees Cloudflare's certificate, not your server's; for problems between Cloudflare and your server see Cloudflare errors 521, 522, 525, 526.