Skip to content

SSL_ERROR_RX_RECORD_TOO_LONG: Non-TLS Response

TL;DR:

SSL_ERROR_RX_RECORD_TOO_LONG means Firefox expected TLS but received HTTP or other plain text. 90% of cases: server is listening on port 443 as HTTP (not HTTPS). Check your nginx/apache config: port 443 needs ssl_certificate and listen 443 ssl.

This error is a frequent issue in SSL debugging. We cover the causes and step-by-step fix.

Check your site's SSL →

What SSL_ERROR_RX_RECORD_TOO_LONG means

SSL_ERROR_RX_RECORD_TOO_LONG means Firefox expected TLS but received HTTP or other plain text. 90% of cases: server is listening on port 443 as HTTP (not HTTPS). Check your nginx/apache config: port 443 needs ssl_certificate and listen 443 ssl.

The error can appear in Chrome, Edge, Opera, Brave (all Chromium-based), and partially in Firefox and Safari. Different browsers display the same code differently, but the underlying issue is the same.

How to fix (step-by-step)

  1. Check the SSL certificate online — the Enterno.io checker shows the grade, expiry, chain, and specific cause.
  2. If the issue is server-side — reissue the certificate via certbot or your chosen CA.
  3. Update nginx/apache config (enable TLS 1.2/1.3, fullchain, correct ciphers).
  4. Check kernel OpenSSL — an outdated openssl < 1.1 can break handshakes.
  5. After deploy: recheck via SSL checker + clear the browser SSL cache.

Check SSL now →

Related SSL errors

TL;DR: How to Fix SSL_ERROR_RX_RECORD_TOO_LONG

The SSL_ERROR_RX_RECORD_TOO_LONG error usually indicates an issue with your SSL configuration or a miscommunication between the client and server. To resolve it, ensure that your server is configured to use the correct SSL port (typically port 443), verify that your SSL certificate is correctly installed and valid, and check for any misconfigurations in your web server settings.

Understanding SSL_ERROR_RX_RECORD_TOO_LONG

The SSL_ERROR_RX_RECORD_TOO_LONG error is a common issue encountered when establishing a secure connection over HTTPS. This error generally occurs when the server fails to properly handle the SSL handshake, leading to a situation where the client receives an unexpected response. Here are the primary causes of this error:

  • Incorrect Port Configuration: SSL connections must be made over port 443. If your server is configured to handle HTTPS traffic on a different port, this error may occur.
  • Misconfigured Web Server: If your web server is not set up correctly to serve SSL certificates, it may send back plain HTTP responses instead of the expected SSL handshake.
  • Invalid SSL Certificate: An expired or improperly installed SSL certificate can also lead to this error, as the server cannot establish a secure connection.
  • Firewall or Proxy Issues: Sometimes, a firewall or proxy may interfere with SSL traffic, causing the error to appear.

To effectively troubleshoot and resolve the SSL_ERROR_RX_RECORD_TOO_LONG error, it is essential to systematically check each of these potential causes.

Practical Steps to Fix SSL_ERROR_RX_RECORD_TOO_LONG

To fix the SSL_ERROR_RX_RECORD_TOO_LONG error, follow these practical steps:

  1. Check Server Configuration: Ensure that your server is listening on the correct port for HTTPS. Use the following command to check which services are running on port 443:
sudo netstat -tuln | grep :443

If you do not see your web server (e.g., Apache, Nginx) listening on port 443, you will need to configure it accordingly.

  1. Verify SSL Certificate Installation: Make sure your SSL certificate is installed correctly. For Apache, you can check the configuration file (usually located in /etc/httpd/conf.d/ or /etc/apache2/sites-available/) to ensure that the SSLCertificateFile and SSLCertificateKeyFile directives point to the correct certificate files:
SSLCertificateFile /etc/ssl/certs/your_cert.crt
SSLCertificateKeyFile /etc/ssl/private/your_private.key

After making changes, restart your web server:

sudo systemctl restart apache2
  1. Check for Mixed Content: Ensure that your website is not trying to load resources over HTTP when accessed via HTTPS. Use browser developer tools to identify any mixed content issues.
  2. Test Your SSL Configuration: Utilize online tools like SSL Labs' SSL Test to verify your SSL configuration. This tool will provide detailed feedback on any issues related to your SSL setup.
  3. Review Firewall Rules: If you're using a firewall, ensure that it allows traffic on port 443. You can list your firewall rules using:
sudo ufw status

Make sure that HTTPS traffic is allowed. If not, add a rule:

sudo ufw allow 'Nginx Full'

or

sudo ufw allow 'Apache Full'

By following these steps, you should be able to diagnose and resolve the SSL_ERROR_RX_RECORD_TOO_LONG error effectively.

CertificateExpiry, issuer, domains (SAN)
ChainIntermediate and root CA validation
TLS ProtocolTLS version and cipher suite
VulnerabilitiesHeartbleed, POODLE, weak ciphers

Why teams trust us

TLS 1.3
supported
Full
CA chain check
<2s
result
30/14/7
days-to-expiry alerts

How it works

1

Enter domain

2

TLS chain verified

3

Expiry date & vulnerabilities

What Does the SSL Check Cover?

SSL/TLS is the encryption protocol that protects data between the browser and server. Our tool analyzes the certificate, chain of trust, TLS version, and knownvulnerabilities.

Certificate Details

Issuer, validity period, signature algorithm, covered domains (SAN), and validation type (DV/OV/EV).

Chain of Trust

Full chain verification: from leaf certificate through intermediates to root CA.

TLS Analysis

Protocol version (TLS 1.2/1.3), cipher suites, Perfect Forward Secrecy (PFS) support.

Expiry Alerts

Set up a monitor — get Telegram and email alerts 30/14/7 days before expiration.

DV vs OV vs EV Certificates

DV (Domain Validation)
  • Confirms domain ownership only
  • Issued in minutes automatically
  • Free via Let's Encrypt
  • Suitable for most websites
  • Most common certificate type
OV / EV
  • Organization (OV) or Extended Validation (EV)
  • Issued in 1-5 business days
  • Costs $50 to $500/year
  • For finance, e-commerce, government sites
  • Increases user trust

Who uses this

DevOps

SSL certificate monitoring

Security

TLS config audit

SEO

HTTPS as ranking factor

E-commerce

customer trust

Common Mistakes

Expired certificateBrowsers block sites with expired SSL. Set up auto-renewal or monitoring.
Incomplete certificate chainWithout intermediate CA, some browsers and bots cannot verify the certificate.
Mixed content on HTTPS siteHTTP resources on an HTTPS page — the browser lock icon disappears, reducing trust.
Using TLS 1.0/1.1Legacy TLS versions have known vulnerabilities. Use TLS 1.2+ or 1.3.
Domain mismatch in certificateThe certificate must cover all site domains, including www and subdomains.

Best Practices

Set up auto-renewalLet's Encrypt + certbot with cron — certificate renews automatically every 60-90 days.
Enable HSTSStrict-Transport-Security header forces browsers to always use HTTPS.
Use TLS 1.3TLS 1.3 is faster (1-RTT handshake) and safer — legacy ciphers removed.
Monitor expiration datesCreate a monitor on Enterno.io — get notified well before expiration.
Verify chain after renewalAfter certificate renewal, confirm that intermediate certificates are installed.

Get more with a free account

SSL certificate monitoring, check history and alerts 30 days before expiry.

Sign up free

Learn more

Sources

Frequently Asked Questions

Is it safe to ignore SSL_ERROR_RX_RECORD_TOO_LONG?

No. This error indicates a real SSL certificate problem. Ignoring it (via chrome://flags or "thisisunsafe") makes the connection vulnerable to man-in-the-middle attacks. Fix it on the server side.

How can I catch this error early?

Use the <a href="/en/ssl">Enterno.io SSL/TLS checker</a>, or <a href="/en/monitors">set up monitoring</a> with 14-day expiry alerts. Receive an email/Telegram notification before your users see the error.

Does clearing cookies / cache help?

Sometimes, for transient cached SSL errors. Steps: chrome://net-internals/#sockets → Flush sockets, chrome://net-internals/#hsts → Delete domain security policies (carefully, for debugging only). But if the issue is server-side, cache clearing will not help.

Is Let's Encrypt free — and is the certificate trusted?

Yes, Let's Encrypt certificates are in every modern trust store (Chrome, Firefox, Safari, Edge). 90-day validity with automatic renewal via certbot. No reason to use a paid CA for a standard website.

Try the live tool that powered this guide

Free plan — 10 monitors, checks every 5 min, no card required. Upgrade for 1-minute interval and multi-region monitoring.