SSL_ERROR_RX_RECORD_TOO_LONG Fix Explained

SSL_ERROR_RX_RECORD_TOO_LONG is a Firefox SSL error that typically means the server is responding with plain HTTP on a port the browser expected to be HTTPS (port 443). When Firefox tries to complete an SSL handshake, it receives an unencrypted HTTP response instead — which appears as an oversized, malformed SSL record.

Chrome shows the same underlying issue as ERR_SSL_PROTOCOL_ERROR. Both mean the same thing: something is wrong with how your server is handling HTTPS.

The Core Cause

Your web server is not configured to serve SSL on port 443. Instead, it's either:

1. Serving plain HTTP on port 443 (misconfiguration)
2. Not listening on port 443 at all, and a different service (or nothing) is responding
3. SSL certificate not loaded — the server falls back to unencrypted responses

Diagnose It

# Check if port 443 is open and what's listening
ss -tlnp | grep :443

# Test SSL connection directly
openssl s_client -connect yourdomain.com:443

# If the openssl output starts with "HTTP/1.1" instead of SSL handshake output,
# your server is sending plain HTTP on port 443

If openssl s_client returns an HTTP response (you'll see HTTP/1.1 200 OK or similar in the output), your server is sending plain text instead of beginning an SSL handshake.

Fix 1: Nginx Not Configured for SSL on Port 443

Check your Nginx configuration:

grep -r "listen 443" /etc/nginx/

If you see listen 443 but no ssl keyword, that's the problem:

# Wrong — no SSL
server {
    listen 443;
    server_name yourdomain.com;
    # ...
}

# Correct — with SSL
server {
    listen 443 ssl;
    server_name yourdomain.com;
    ssl_certificate /etc/ssl/certs/yourdomain.crt;
    ssl_certificate_key /etc/ssl/private/yourdomain.key;
    # ...
}

After fixing:

nginx -t && systemctl reload nginx

Fix 2: Apache Not Configured for SSL

# Check if mod_ssl is enabled
apache2ctl -M | grep ssl

# Enable mod_ssl if not present
a2enmod ssl
a2ensite default-ssl
systemctl reload apache2

Check your virtual host file:

<VirtualHost *:443>
    ServerName yourdomain.com
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/yourdomain.crt
    SSLCertificateKeyFile /etc/ssl/private/yourdomain.key
    # ...
</VirtualHost>

If SSLEngine on is missing, SSL won't be active even with certificates present.

Fix 3: Certificate Not Installed After Renewal

If this error appeared after a certificate renewal, the new certificate may not have been loaded:

# Check what certificate is actually being served
echo | openssl s_client -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates

# If this fails (SSL handshake fails), the certificate isn't loading

Check whether your post-renewal reload hook ran correctly. If using Let's Encrypt with Certbot, ensure the deploy hook reloads your web server. See Let's Encrypt renewal failed: common causes and fixes for the full troubleshooting process.

Fix 4: Port 80 Redirect Sending to Port 443 on HTTP

Some setups redirect HTTP (port 80) to HTTPS (port 443) but the SSL configuration on port 443 isn't working. The browser ends up on port 443 receiving an HTTP response.

# Port 80 block — this is fine
server {
    listen 80;
    return 301 https://$host$request_uri;
}

# Port 443 must have SSL configured — if this block is missing or broken,
# you get SSL_ERROR_RX_RECORD_TOO_LONG
server {
    listen 443 ssl;
    # ...
}

Monitoring SSL Correctly

This error often emerges silently after a configuration change, migration, or certificate renewal that went wrong. By the time users report it, the outage has been running for some time.

Domain Monitor monitors your SSL certificate validity and your site's HTTPS response. A failed SSL handshake shows up as a monitor failure within minutes. Create a free account to catch SSL issues before users do.

Related Troubleshooting

• ERR_TOO_MANY_REDIRECTS Fix: A Complete Guide
• Let's Encrypt Renewal Failed: Common Causes and Fixes
• How to Rotate SSL Certificates Without Breaking Your Site
• 521 vs 522 vs 524 Cloudflare Errors: What's the Difference?