How to Fix SSL_ERROR_RX_RECORD_TOO_LONG

What SSL_ERROR_RX_RECORD_TOO_LONG actually means

When your browser opens an HTTPS connection, it expects the server to reply with TLS handshake records. The first couple of bytes of a TLS record encode its type and length. If the server instead replies with a plain HTTP response, starting with text like "HTTP/1.1 200 OK"the browser tries to read those ASCII bytes as a TLS record length. It comes out as an absurdly large number, the browser decides the record is too long to be legitimate, and it aborts with SSL_ERROR_RX_RECORD_TOO_LONG.

So the message is really telling you: I asked for TLS and got something that is not TLS. Chrome shows the same underlying problem as ERR_SSL_PROTOCOL_ERROR. The certificate is usually irrelevant, the server is speaking the wrong protocol on the port you connected to.

The usual causes

Nearly every instance of this error comes down to a port that is serving plain HTTP where TLS was expected. The common culprits:

• Port 443 configured to serve plain HTTP, for example an nginx block with listen 443; but no ssl keyword, so it answers 443 in cleartext.
• A virtual host on 443 with no SSL engine enabled or no certificate directives, so the server falls back to plaintext.
• Connecting with https:// to a port that only speaks HTTP, such as https://example.com:80 or a custom app port.
• A reverse proxy or load balancer terminating TLS upstream while the origin block still expects to, leaving 443 answering in the clear.
• A firewall or proxy redirecting 443 traffic to an HTTP-only backend.

Diagnosing it in two minutes

Before editing config, confirm the port is not speaking TLS. From a terminal, ask openssl to start a TLS handshake directly:

Once you have confirmed the server is answering 443 with HTTP, the fix is a configuration change, not a certificate reinstall.

• openssl s_client -connect example.com:443a healthy port returns certificate details; a broken one hangs, errors, or dumps back an HTTP response, which tells you 443 is plaintext.
• curl -v https://example.comwatch for a TLS handshake in the verbose output. If curl reports it received an HTTP response where the handshake should be, that is your smoking gun.
• Try the plain-HTTP form in a browser, http://example.com (or on the specific port). If that loads fine while https:// fails, the content is being served without TLS.

Fixing it on nginx and Apache

On nginx, the classic mistake is omitting the ssl keyword. The listen directive must enable TLS and point to a valid certificate and key:

If the certificate files themselves are the question, expired, wrong path, or a broken chain, the fix is different; walk through what to do when an SSL certificate has expired. And verify the live result with a free SSL checker to see the served chain rather than trusting a reload that reported success.

• nginx: use listen 443 ssl; (not listen 443;) and set ssl_certificate and ssl_certificate_key to your fullchain and private key files, then nginx -t and reload.
• Apache: ensure mod_ssl is enabled (a2enmod ssl), wrap the site in <VirtualHost *:443>, and inside it set SSLEngine on plus SSLCertificateFile and SSLCertificateKeyFile, then restart.
• Confirm nothing else is bound to 443 in plaintext, a stray default vhost listening on 443 without SSL can shadow your real one.

Preventing a repeat

This error most often shows up right after a change, a new vhost, a cert renewal, a migration, or a proxy tweak, because a config edit quietly dropped the ssl keyword or pointed 443 at the wrong backend. The failure is total (the site is unreachable over HTTPS), so you want to hear about it from a monitor, not from a customer.

Continuous SSL and domain monitoring catches exactly this: it connects over TLS on a schedule and flags when the handshake stops working or the certificate changes unexpectedly. Pair that with the distinction in SSL monitoring vs uptime monitoring, a plain uptime check that follows HTTP can look green while HTTPS is completely broken.