Error guide / SSL_ERROR_RX_RECORD_TOO_LONG

SSL_ERROR_RX_RECORD_TOO_LONG error in Firefox

SSL_ERROR_RX_RECORD_TOO_LONG is how Firefox reports that it opened a TLS connection on port 443 and got back something that was not TLS. In practice the server answered with a plain HTTP response, Firefox tried to read those first bytes as a TLS record, saw an impossible record length, and gave up. Chrome shows the same situation as ERR_SSL_PROTOCOL_ERROR, so a page that fails in Firefox usually fails everywhere. You normally meet it right after switching a site to HTTPS, or when the address points at a port that serves plain HTTP.

Check your site

>

What causes it

Most often a virtual host is listening on port 443 without SSL actually enabled, so the web server accepts the connection and replies in plain HTTP. Next most common is a proxy, load balancer or CDN in front of the site that terminates TLS incorrectly or forwards the request to a backend port that only speaks HTTP. Third, the site really runs on a non-standard port while the URL says 443, or someone typed https:// against a port that serves plain HTTP, which produces exactly the same message. Least often, a firewall, an antivirus with HTTPS scanning, or a captive portal on public Wi-Fi intercepts the connection and answers with something that is not TLS.

How to fix it

  1. Run the check on this page for your domain. It opens a real TLS connection on port 443: if it shows a certificate, the server does speak TLS and the failure is local to you; if it reports that TLS could not be established, the failure is server-side and the fix is in the vhost or proxy configuration.
  2. If the check showed a certificate, work through your own machine and network: open the site in a Firefox private window, turn off antivirus HTTPS or SSL scanning, disable any proxy or VPN, and on public Wi-Fi load the captive portal login page first. Opening the same URL over mobile data confirms it in a minute.
  3. If the check could not establish TLS either, open the server configuration for port 443. In Apache the SSL vhost needs SSLEngine on together with SSLCertificateFile and SSLCertificateKeyFile; in nginx the line must be listen 443 ssl; and not listen 443;. Validate with apachectl configtest or nginx -t, then reload the web server.
  4. On a hosting control panel you do not edit vhosts by hand: reinstall or reissue the certificate for that exact hostname, including the www version, and the panel rewrites the SSL vhost for you. On your own server also check what is really bound to 443 with ss -ltnp, because another service holding the port will answer instead of your web server.
  5. If a proxy, load balancer or CDN sits in front, decide which layer terminates TLS and check where it forwards. The classic break is passing port 443 straight through to a backend that only serves HTTP: either terminate TLS at the proxy and forward to the backend's HTTP port, or install a certificate on the backend and speak TLS to it.
  6. Check the port in the address bar. A site on a non-standard port must be reached as https://example.com:8443, and typing https:// against a port that serves plain HTTP gives this same error even when the site itself is fine. After every change, reload the server and re-run the check above to see whether the handshake now completes.

Related errors