Is SSL_ERROR_RX_RECORD_TOO_LONG a certificate problem?

Almost never. The certificate never gets a chance to be evaluated. This error fires at the very first byte of the TLS handshake: Firefox reads what it expects to be a TLS record, sees a length field that makes no sense, and gives up before any certificate is exchanged. The usual cause is that the server on port 443 is speaking plain HTTP, not TLS at all — so there is no handshake and no certificate to check.

Why does Chrome show a different error for the same site?

Every browser detects the same underlying fault — a non-TLS response on the HTTPS port — but names it differently. Firefox uses its NSS library's SSL_ERROR_RX_RECORD_TOO_LONG. Chrome typically shows ERR_SSL_PROTOCOL_ERROR. The server-side cause is identical; the checklist below fixes both.

It works on port 80 but not 443. What does that tell me?

That the application itself is fine and the problem is purely in the TLS listener. Port 80 answers plain HTTP correctly, but nothing is terminating TLS on 443 — either no HTTPS listener exists, or the listener is misconfigured to serve plain HTTP. The fix is in the web server's SSL configuration, not the app.

Views: 111

SSL_ERROR_RX_RECORD_TOO_LONG in Firefox: Fix

SSL_ERROR_RX_RECORD_TOO_LONG usually means plain HTTP on port 443. Fix in 3 checks: the ssl directive, the port, the proxy. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Firefox refuses to load the page with SSL_ERROR_RX_RECORD_TOO_LONG. The full message is usually “Secure Connection Failed… An error occurred during a connection… SSL received a record that exceeded the maximum permissible length.”

Symptoms

Firefox shows SSL_ERROR_RX_RECORD_TOO_LONG; the page never loads.
The http:// version of the site works fine; only https:// fails.
Chrome shows ERR_SSL_PROTOCOL_ERROR on the same URL, or Safari says “can’t establish a secure connection.”
The site loads fine over HTTPS from some networks but not others (a proxy is involved).

What This Error Actually Means

Read the error literally: SSL received a record that was too long. A TLS record has a header that starts with a content type byte and a two-byte length. Firefox opens the connection, expects the server’s first bytes to be a ServerHello TLS record, and instead reads bytes that, when interpreted as a TLS record length, come out absurdly large. It concludes the record is corrupt or oversized and aborts.

The reason those bytes look like garbage is almost always simple: they aren’t TLS at all. The server on port 443 answered with plain, unencrypted HTTP. The first bytes of an HTTP response are HTTP/1.1 200 OK.... Firefox tries to parse the ASCII H, T, T, P as a TLS record header and a length field, and the “length” it computes is enormous. Hence: record too long.

So this is not a certificate error, not a cipher-negotiation error, and not a protocol-version mismatch. Nothing about the certificate has been evaluated, because the handshake never started. Firefox exposes this more readily than Chrome because NSS is strict about the very first record it reads.

Top 3 Causes

Plain HTTP is being served on port 443 - The single most common cause. In nginx, listen 443; without the ssl keyword makes the server answer 443 with unencrypted HTTP. The correct directive is listen 443 ssl;. In Apache, a <VirtualHost *:443> without SSLEngine on does the same thing.
No TLS listener exists on 443 at all - The HTTPS listener was never configured, or a firewall/port-forward sends 443 traffic to a backend that only speaks HTTP. The app answers, but in cleartext.
An intermediary strips or breaks TLS - A corporate proxy, a misconfigured load balancer, or a port-forwarding rule that terminates TLS incorrectly and forwards plain HTTP. This is why the error can appear only on certain networks.

Diagnose with DechoNet

SSL Check to see whether the server presents a valid certificate on 443 at all. If TLS is actually configured, you get certificate details; if plain HTTP is being served, the TLS probe fails at the handshake — which confirms this diagnosis.
Port Check to confirm 443 is open and reachable, separating “no listener” from “wrong listener.”
HTTP Check to confirm the application itself responds on 80/443 so you know the app is healthy and the fault is isolated to the TLS layer.

Resolution Checklist

Confirm the pattern: does http:// work while https:// fails? If yes, the app is fine and TLS termination is the problem.
In nginx, check every listen 443 line has the ssl keyword: listen 443 ssl; (and listen [::]:443 ssl; for IPv6). A bare listen 443; is the classic cause.
In Apache, confirm the :443 virtual host has SSLEngine on and a valid SSLCertificateFile / SSLCertificateKeyFile.
Run SSL Check against the host. If it cannot complete a handshake but Port Check shows 443 open, the listener is serving non-TLS traffic.
If a load balancer or proxy sits in front, verify it terminates TLS on 443 and isn’t forwarding plain HTTP to the client.
Reload the web server and re-run SSL Check to confirm a real certificate is now presented.

When to Escalate

Escalate to whoever manages the load balancer or CDN if SSL Check shows a healthy certificate at the origin but the error persists through the edge — the plain-HTTP response is being generated between the edge and the browser.
If the site was recently migrated or a certificate was just installed, suspect a half-applied config: the certificate exists on disk but the ssl directive or SSLEngine was never enabled on the 443 listener.