Browser errors

Fixing SSL_ERROR_RX_RECORD_TOO_LONG

This error occurs when a client attempting a TLS handshake receives a response that doesn't look like valid TLS data at all — the most common cause is a server listening on port 443 but actually serving plain HTTP there, rather than a proper TLS-wrapped response.

The fix

Verify your web server actually has an SSL/TLS configuration block bound to port 443 — this error often shows up specifically when someone forwards port 443 to an application or service that only speaks plain HTTP, without an intervening TLS-terminating proxy or web server actually handling the encryption.

What this Firefox-specific error typically indicates

This specific error, most commonly seen in Firefox, typically means the browser attempted an HTTPS connection to a port or service actually running plain HTTP rather than TLS — the browser receives an unexpectedly large, non-TLS-formatted response where it expected a TLS handshake.

How to confirm whether the underlying service is really running HTTPS at all

Connecting directly with OpenSSL's s_client to the specific port and hostname shows immediately whether a genuine TLS handshake is attempted at all — if the connection behaves like plain HTTP rather than initiating TLS negotiation, the server simply isn't running HTTPS on that port regardless of what URL scheme you're trying to use.

What to check to confirm whether HTTPS is genuinely configured on the expected port

Testing the URL with plain HTTP instead of HTTPS, or checking with OpenSSL's s_client against the specific port, quickly confirms whether the underlying service is actually running HTTPS at all, or whether this error is correctly identifying an HTTP-only service being accessed via an https:// URL.

How this error compares to how other browsers report the identical underlying issue

Chrome and Safari typically report this same underlying HTTP-on-HTTPS-port scenario with their own differently worded but conceptually equivalent messages — the specific wording differs by browser, but the underlying cause and fix (confirming the server actually runs HTTPS on the expected port) remains the same regardless of which browser reports it.

A final note for newly deployed services specifically

If you're testing a newly deployed service and encounter this error, double-checking your deployment or infrastructure configuration for a port mapping mistake, HTTPS traffic accidentally routed to an HTTP-only backend, resolves the underlying misconfiguration directly rather than continuing to investigate the symptom.

What Firefox is specifically doing differently that produces this particular error message

Firefox's TLS implementation produces this specific, technically-worded error when it receives a response that doesn't match the expected TLS record format at all — essentially detecting that whatever answered on the expected HTTPS port isn't actually speaking TLS, which is exactly what happens when HTTP is unexpectedly served on port 443.

How to fix the underlying misconfiguration once you've confirmed HTTP is being served on the HTTPS port

Reconfiguring your web server or proxy to correctly serve HTTPS on port 443, rather than accidentally routing HTTP traffic there, resolves this error definitively — the specific fix depends on your infrastructure, but always involves correcting which protocol is actually bound to that port.

A quick closing checklist

A quick closing checklist covers testing the specific port directly with OpenSSL to confirm what's actually running there, checking for a misconfigured reverse proxy or load balancer routing HTTP to the HTTPS port, and correcting the underlying port binding once identified.

Why this error is a useful example of how browsers infer meaning from malformed-looking responses

Rather than simply failing generically, Firefox's specific interpretation of this raw, unexpected response as 'not TLS at all' demonstrates how modern browsers attempt to provide genuinely diagnostic error messages rather than only generic connection failures.