Skip to content

SSL_ERROR_RX_UNKNOWN_RECORD_TYPE

Key idea:

SSL_ERROR_RX_UNKNOWN_RECORD_TYPE — Firefox received a TLS record with unknown content type (not 20, 21, 22, 23, 24). Frequent: MITM proxy inserting garbage, HTTP error page served on an HTTPS port (80 vs 443 mix-up), captive portal interception, or broken load balancer. Fix: confirm the server actually speaks TLS on 443.

Below: causes, fixes, FAQ.

Check your site's SSL →

Common Causes

  • HTTP server listens on 443 (nginx misconfig)
  • Captive portal (hotel Wi-Fi) intercepts and returns HTML
  • MITM proxy with broken TLS handling
  • Broken load balancer forwards non-TLS
  • nginx stream module routes wrong (TCP pass-through broken)

Step-by-Step Fix

  1. openssl s_client -connect host:443 — should show TLS handshake
  2. curl -vI https://host — HTTP/2 200 ok?
  3. Check nginx config: listen 443 ssl — did you forget ssl?
  4. Test from another network — captive portal issue?
  5. Enterno SSL for external validation

Check SSL Certificate →

Related SSL Errors

TL;DR

The SSL_ERROR_RX_UNKNOWN_RECORD_TYPE error in Firefox indicates that the browser received an unknown record type during the SSL/TLS handshake, often due to misconfigured servers, incompatible protocols, or corrupted browser caches. To resolve this, ensure your server is configured to support TLS 1.2 or higher, clear your browser's cache, and verify that your SSL certificate is correctly installed and valid.

Understanding SSL_ERROR_RX_UNKNOWN_RECORD_TYPE

The SSL_ERROR_RX_UNKNOWN_RECORD_TYPE error is a common issue encountered by Firefox users when attempting to establish a secure connection to a website. This error signifies that the browser has received an unexpected or unrecognized record type from the server during the SSL/TLS handshake process. The handshake is a critical phase in establishing a secure connection, where both the client (browser) and server agree on the encryption methods and keys to be used.

Several factors can contribute to this error:

  • Server Misconfiguration: Incorrect server settings or outdated software can lead to incompatibilities with modern browsers.
  • Protocol Mismatch: If the server does not support the required SSL/TLS versions (TLS 1.2 or higher), the browser may not be able to establish a secure connection.
  • Corrupted Cache: Cached data or cookies in the browser can interfere with the SSL handshake.
  • Invalid SSL Certificate: An improperly configured or expired SSL certificate can also trigger this error.

Understanding the underlying causes of the SSL_ERROR_RX_UNKNOWN_RECORD_TYPE error is essential for troubleshooting and resolving the issue effectively.

Troubleshooting Steps to Fix SSL_ERROR_RX_UNKNOWN_RECORD_TYPE

To resolve the SSL_ERROR_RX_UNKNOWN_RECORD_TYPE error in Firefox, follow these systematic troubleshooting steps:

  1. Check SSL/TLS Configuration: Ensure your server supports TLS 1.2 or higher. You can verify this by running the following command in your terminal:
openssl s_client -connect yourdomain.com:443 -tls1_2

If the connection is successful, your server supports TLS 1.2. If it fails, you may need to update your server configuration.

  1. Clear Browser Cache: A corrupted cache can cause handshake issues. To clear the cache in Firefox:
  1. Click on the menu button (three horizontal lines) in the top right corner.
  2. Select Settings.
  3. Go to Privacy & Security.
  4. Under Cookies and Site Data, click on Clear Data.
  5. Check both options and click Clear.
  1. Verify SSL Certificate: Use an SSL checker tool (e.g., SSL Shopper) to ensure that your SSL certificate is correctly installed and valid. Look for any warnings or errors that need addressing.
  1. Check Server Logs: Review your server logs for any error messages related to SSL/TLS connections. This can provide insights into why the handshake is failing.
  1. Disable QUIC Protocol: In some cases, the QUIC protocol can cause compatibility issues. To disable QUIC in Firefox:
  1. Type about:config in the address bar and press Enter.
  2. Search for network.http.http3.enabled.
  3. Double-click the setting to change it from true to false.

After completing these steps, restart Firefox and try accessing the website again. If the error persists, consider reaching out to your hosting provider for further assistance.

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

Captive portal — how to tell?

From hotel/cafe Wi-Fi — yes. Try mobile hotspot. Error gone → captive portal. Usually a 302 redirect over HTTP.

nginx "listen 443" without ssl?

Fatal config error. nginx serves plain HTTP on 443, client sends TLS, server answers plain HTTP → garbage bytes.

MITM detection?

Cert pinning / HPKP (deprecated) / DANE. Or compare cert fingerprint: <code>openssl s_client | openssl x509 -fingerprint</code>.

TLS record types?

ChangeCipherSpec(20), Alert(21), Handshake(22), ApplicationData(23), Heartbeat(24). Anything else is malformed.

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.