SSL_ERROR_RX_RECORD_TOO_LONG in Firefox
Firefox tried to start TLS on port 443 but got back plain HTTP or junk, so it aborts before any page loads.
What you see
Secure Connection Failed An error occurred during a connection to example.com. SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG
What’s actually happening
Firefox sends a TLS ClientHello to port 443 and the bytes that come back aren't a TLS record — they're plaintext HTTP, an HTML error page, or noise. Firefox reads the length field of the "record," sees a value far bigger than any real TLS record, and bails. Chrome hits the same server and usually shows ERR_SSL_PROTOCOL_ERROR instead, which is a useful tell that the problem is server-side, not your browser. It fails on every load, and an incognito/private window behaves identically.
Common causes
- The vhost listening on 443 is serving plain HTTP — e.g. an Apache <VirtualHost *:443> block with no `SSLEngine on`, or an Nginx `listen 443;` missing the `ssl` keyword.
- HTTPS is pointed at the wrong port: the TLS service actually lives on 8443 (or similar) and 443 is answering with a bare HTTP daemon.
- Cloudflare or another proxy is set to "Flexible" SSL while the origin only speaks HTTP, so the leg the browser hits is effectively cleartext on 443.
- Antivirus or a corporate proxy (Avast/AVG Web Shield, Kaspersky, ESET, BitDefender HTTPS scanning) is intercepting the connection and returning a malformed record.
- A load balancer or CDN is forwarding raw HTTP to an origin that expects TLS, or terminating TLS on the wrong listener.
How to fix it
- Confirm what's actually on 443Run `openssl s_client -connect example.com:443`. A healthy TLS server prints a certificate chain; a broken one returns `wrong version number` or dumps an HTML/HTTP response. If you see HTTP text, the port is serving cleartext — that's the whole bug.
- Turn on TLS for the 443 listenerNginx: the listen line must read `listen 443 ssl;` with `ssl_certificate` / `ssl_certificate_key` set in that same server block. Apache: inside `<VirtualHost *:443>` you need `SSLEngine on` plus `SSLCertificateFile`/`SSLCertificateKeyFile`. Reload (`nginx -s reload` / `apachectl graceful`) and re-test with openssl.
- Point HTTPS at the right portIf TLS really runs on 8443, either move it to 443 or have the front-end proxy listen on 443 with `ssl` and pass to the backend. Don't leave a plain HTTP server squatting on 443.
- Fix the proxy SSL modeOn Cloudflare, switch SSL/TLS from Flexible to Full (strict) and install a real cert on the origin so the browser-facing leg is genuinely encrypted. Flexible re-exposes HTTP and is a common source of this on otherwise-working sites.
- Rule out local interceptionIf only one machine fails, disable the antivirus "HTTPS/SSL scanning" feature (or its root cert) and retry. AV MITM that mangles the record will throw this on every HTTPS site, not just yours.
Stop it recurring
After any TLS or proxy change, verify with `openssl s_client -connect host:443` before trusting the browser — it tells you in one line whether 443 is really speaking TLS.