LiveChat 
Support 
SSL_ERROR_RX_RECORD_TOO_LONG: What It Means and How to Fix It
If you have just hit a page that refuses to load and your browser threw back `ssl_error_rx_record_too_long`, take a breath. This is one of the more intimidating-looking SSL errors, mostly because the name reads like a database crash dump. But the message is actually very honest about what went wrong, and in the overwhelming majority of cases it points to a single, fixable problem on the server.
In plain terms, `ssl_error_rx_record_too_long` means your browser asked for a secure, encrypted connection on the HTTPS port, but the server replied with something that isn’t proper encryption — almost always plain, unencrypted HTTP. The browser was expecting an encrypted TLS handshake and got gibberish instead, so it gave up and showed you this error. It is a Firefox-style message in particular, though every browser hits the same underlying condition under different wording.
The good news: this is almost never a problem with your computer, your browser, or your network. It is a server configuration issue, which means it has a clear cause and a clear fix.
Key Takeaways
• `ssl_error_rx_record_too_long` means the browser expected encrypted TLS on port 443 but the server answered with plain HTTP instead.
• The number-one cause is that real SSL/TLS is not actually being served on the HTTPS port — either no certificate is installed, or the web server is misconfigured to serve plain HTTP on 443.
• It is almost always a server-side problem, not something a visitor can fix.
• The fix is to make port 443 genuinely speak TLS: install or enable a valid certificate and configure the web server correctly.
• Visitors can confirm the diagnosis by loading the `http://` version of the site, but they cannot fix the underlying misconfiguration.
What does ssl_error_rx_record_too_long actually mean?
When your browser connects to an `https://` address, it connects to port 443 and immediately expects to begin a TLS handshake. TLS data travels in structured chunks called records, each with a defined header and a maximum length. The browser reads the first few bytes, interprets them as a record header, and works out how long the encrypted record should be.
Here is where the error name comes from. If the server answers with plain HTTP text instead of a TLS record — something like `HTTP/1.1 200 OK` followed by ordinary headers — the browser tries to interpret that plain text as a TLS record header anyway. Decoded as binary, that text translates into an absurdly large length value. The browser sees a “record” that claims to be far longer than TLS allows, decides the response is malformed, and aborts with “rx record too long” — literally, *the record I received is too long.*
The cryptic name is hiding a wonderfully specific meaning. The “rx” stands for receive: the browser connected to the HTTPS port expecting to *receive* encrypted TLS records, but what came back wasn’t TLS at all — it was almost always plain, unencrypted HTTP. To the TLS parser, that plain-text response looks like a single, malformed, absurdly-long record, hence “rx record too long.” Decoded, the error is really saying: *”I asked for HTTPS and the server answered in HTTP.”* That single sentence tells you exactly where to look. The site isn’t actually serving real SSL/TLS on port 443 — either no certificate is installed, or the server is misconfigured to serve plain HTTP on the secure port. This is almost never a visitor problem and almost always a server-side SSL configuration problem: the encryption the browser expected simply isn’t there. The fix, therefore, is to make port 443 genuinely serve TLS — install or enable a valid certificate and configure the web server to speak HTTPS on the HTTPS port — rather than anything the visitor can do.
What is the number-one cause of this error?
The single most common cause is that SSL is not actually installed or configured for the site, or HTTPS is being served on the wrong port so that port 443 is handing back plain HTTP instead of TLS.
Think of it this way. Port 443 is the door marked “secure.” When a browser knocks on that door, it expects whoever answers to speak the encrypted TLS language. If the server behind that door has never been taught to speak TLS — because no certificate exists, or because the configuration accidentally points plain HTTP traffic at port 443 — then the server answers in the wrong language entirely. The browser cannot make sense of the reply and throws `ssl_error_rx_record_too_long`.
Everything else that triggers this error is a variation on the same theme: the secure port is not actually serving secure traffic.
What are the other causes of ssl_error_rx_record_too_long?
Beyond the headline cause, a handful of related misconfigurations produce the identical error:
- A misconfigured virtual host. An HTTPS request lands on a virtual host (server block) that is only set up to handle plain HTTP, so the server replies in HTTP on a TLS connection.
- The wrong port. The site is listening for HTTPS on a non-standard port, or something is listening on 443 that was never meant to handle TLS.
- A proxy or firewall interfering. A reverse proxy, load balancer, or firewall sits between the visitor and the server and forwards plain HTTP to the client even though the connection arrived as HTTPS.
- SSL not enabled for that specific domain. The server has TLS working for some sites but the certificate or SSL configuration was never switched on for this particular domain.
- An HTTP redirect served on 443. The server returns a plain-HTTP redirect response on the secure port instead of completing a TLS handshake first.
Notice the common thread: in every case, the secure port answers in plain HTTP. Identify which of these applies and the fix follows naturally.
Is it your computer or the website?
This is the fastest question to settle, and the answer is almost always *the website.*
Run two quick checks. First, try the site in a different browser — if every browser fails on the same page, the problem is on the server, not in your software. Second, try a different network or device, such as switching from Wi-Fi to mobile data. If the error persists everywhere, you have confirmed it is server-side.
You can also load the `http://` version of the address (without the “s”). If the unencrypted version loads fine while the `https://` version throws the error, that is the smoking gun: the site works in plain HTTP but has no working TLS on port 443. That is a server configuration problem the site owner must resolve. Use `http://` for diagnosis only — never as a permanent workaround, since it leaves the connection unencrypted.
Cause and fix at a glance
| Cause | Fix |
|---|---|
| No SSL certificate installed for the domain | Install and enable a valid certificate for the exact domain |
| Web server serving plain HTTP on port 443 | Configure the server to perform TLS on 443, not plain HTTP |
| Misconfigured virtual host / server block | Point HTTPS requests to an SSL-enabled virtual host |
| HTTPS listening on the wrong port | Set the site to serve HTTPS on the standard port 443 |
| Proxy or firewall forwarding plain HTTP | Configure the proxy/firewall to terminate or pass TLS correctly |
| SSL not enabled for this specific domain | Enable SSL for the domain in your hosting or server config |
| HTTP redirect returned on 443 | Complete the TLS handshake before issuing any redirect |
| Browser cache holding a stale state | Clear cache and retry (diagnostic, visitor-side) |
How do you fix ssl_error_rx_record_too_long? (Site owner)
Because this is a server-side problem, the meaningful fixes belong to whoever runs the site. Work through them in order:
- Confirm a valid SSL certificate is actually installed for the domain. Check your hosting control panel or server configuration and verify a current, non-expired certificate exists *for this exact hostname* — including the `www` and non-`www` variants if both are in use. If there is no certificate, that is your cause.
- Ensure the web server is configured to serve TLS on port 443. Open your web server configuration and confirm the secure port is set up to perform a TLS handshake — not to serve plain HTTP. The listener on 443 must reference the certificate and key and enable SSL/TLS.
- Check the virtual host or server block. Make sure HTTPS requests are routed to a server block that has SSL enabled. A common slip is an HTTPS request falling through to a default, HTTP-only block. The SSL-enabled block must explicitly handle the secure port for your domain.
- Verify port 443 is open and serving HTTPS. Confirm that port 443 is open on the server and any upstream firewall, and that the service answering on it is genuinely speaking TLS. If a proxy or load balancer sits in front, verify it forwards or terminates TLS correctly rather than passing plain HTTP downstream.
- Fix any HTTP-on-443 misconfiguration. If you find the server returning plain HTTP — or a bare HTTP redirect — on port 443, correct it so the secure port completes the encrypted handshake first. Redirects from HTTP to HTTPS belong on port 80, not 443.
- Reinstall or re-enable SSL for the domain. If everything looks correct but the error persists, re-issue or reinstall the certificate and re-enable SSL for the domain, then restart the web server so the new configuration takes effect.
After each change, reload the site over `https://` in a fresh browser tab (or a private window) to test whether the handshake now completes.
What can a visitor do?
Honestly, very little — and that is reassuring, because it confirms the problem is not on your end. Still, a visitor can run these quick steps to rule out a stale local state and confirm the diagnosis:
- Load the `http://` version of the site. If it loads, you have confirmed the site is up but lacks working TLS on the secure port. This is diagnostic only; do not treat it as a fix.
- Clear your browser cache and try again, in case a stale cached redirect or HSTS state is involved.
- Try another browser to confirm the failure is universal and therefore server-side.
If all three confirm the error, the only real fix is for the site owner to correct the server’s SSL configuration. If it is your own site, head back to the owner-side steps above.
Hosting with DarazHost? This particular headache rarely shows up on DarazHost-hosted sites. DarazHost’s free AutoSSL installs and properly configures real TLS on port 443 automatically — so the “server answered HTTP on the HTTPS port” misconfiguration behind `ssl_error_rx_record_too_long` simply doesn’t happen out of the box. You get correctly-served HTTPS from day one, plus 24/7 support if any SSL configuration question ever comes up. If you are wrestling with this error on another setup, it is a strong argument for hosting where secure-by-default is the norm.
Frequently asked questions
Does ssl_error_rx_record_too_long mean my certificate is expired? Not specifically. An expired certificate usually produces a different warning. This error means no proper TLS response came back at all on the secure port — most often because no certificate is installed or the server is serving plain HTTP on 443. An expired certificate is one possible trigger, but the broader cause is missing or misconfigured TLS.
Why does the site load fine over http:// but fail over https://? Because the site is genuinely up and serving content, but only over plain HTTP. The secure port either has no TLS configured or is handing back HTTP. Loading `http://` confirms the diagnosis — the encryption layer is the missing piece — but you should not rely on the unencrypted version permanently.
Is this error caused by my browser or antivirus? Almost never. If it fails across multiple browsers, networks, and devices, the cause is on the server. Antivirus or proxy software *can* occasionally interfere by intercepting traffic, but the default assumption should be a server-side SSL misconfiguration, since that is the cause in the vast majority of cases.
Can I fix ssl_error_rx_record_too_long as a visitor? No. You can clear your cache, switch browsers, or load the `http://` version to confirm the problem, but the real fix — installing a certificate and configuring TLS on port 443 — can only be done by the site owner or host.
What is the fastest way for a site owner to fix it? Confirm a valid certificate is installed for the exact domain, then verify the web server is configured to perform TLS on port 443 rather than serving plain HTTP. Those two checks resolve the large majority of cases.
To understand how certificates, the handshake, and trust fit together end to end, see our pillar guide: SSL Certificates: The Complete Guide to How HTTPS, Encryption, and Trust Work.
For closely related issues, see:
