Diagnose SSL_ERROR_RX_RECORD_TOO_LONG

Trace a TLS connection through listeners, virtual hosts, and proxies to find a protocol mismatch.

Guance Editorial Team 2026-10-27 3 min read Updated 2026-10-27

Illustration of encrypted network connections

SSL_ERROR_RX_RECORD_TOO_LONG often appears when a client expecting TLS receives bytes that are not a valid TLS record, such as a plaintext HTTP response. A service speaking HTTP on an HTTPS port is a common cause, but the error text alone does not identify the misconfigured hop.

Test the listener's protocol

openssl s_client -connect example.com:443 -servername example.com

Use the hostname the client actually requests so the test sends the correct SNI value. Inspect the handshake and any protocol error. A connection closed immediately can also reflect a policy or other handshake problem; it is not conclusive evidence of HTTP.

For a controlled diagnostic without credentials, compare a plaintext request:

curl -v http://example.com:443/

A normal business response suggests an HTTP listener. An HTTP 400 response alone is inconclusive: some TLS servers deliberately return a readable error when they detect plaintext on their TLS port.

Check Apache or Nginx

An Apache TLS virtual host needs SSL enabled and matching certificate files:

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/fullchain.pem
    SSLCertificateKeyFile /etc/ssl/private/server.key
</VirtualHost>

Also check that the server listens on that port and loads mod_ssl. On Debian-style installations, a2enmod ssl enables the module; other distributions have different module configuration.

For Nginx, the listener must enable TLS:

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /etc/ssl/certs/fullchain.pem;
    ssl_certificate_key /etc/ssl/private/server.key;
}

A port number does not select the protocol by itself. Inspect every matching virtual host and SNI name, including the default host on that address.

Follow the connection through proxies

TLS termination at a load balancer followed by HTTP to a backend is a normal design. Forwarding the original encrypted bytes unchanged to an HTTP-only backend is a different operation and will fail. A proxy's upstream scheme must match the backend listener too.

Check NAT mappings, ingress configuration, and nonstandard ports such as 8443. Ordinary security-group filtering controls which traffic is allowed; it does not translate an HTTPS listener into an HTTP listener.

After editing, run nginx -t or apachectl configtest, reload the correct service, and repeat the original request. Include the CDN or load balancer when that is the endpoint users reach. Clearing a browser cache does not correct a server protocol mismatch.

Separate protocol errors from trust errors

A self-signed certificate normally produces a trust error after the server has begun a valid TLS handshake. It is not, by itself, the explanation for a record-length parsing failure. Different browsers can report different messages for the same connection problem, so compare the endpoint and protocol evidence rather than only the wording.

Guance TCP tests and HTTP tests can check connectivity and application responses separately. TCP success with HTTPS failure narrows the investigation; it does not prove the service is returning plaintext.

References: Nginx HTTPS configuration and Apache mod_ssl.