Keywords: Apache | SSL | Troubleshooting
Abstract: This paper provides an in-depth analysis of the common SSL_ERROR_RX_RECORD_TOO_LONG error in Apache servers, which typically occurs in Firefox browsers due to SSL handshake failures. Starting from the error symptoms, it explores potential causes such as port misconfiguration, virtual host issues, improper SSL certificate settings, and local proxy errors. By integrating Q&A data and reference articles, multiple effective solutions are presented, including modifying VirtualHost to _default_, ensuring SSL runs on standard port 443, and verifying SSL certificate validity. Code examples illustrate specific configuration adjustments, aiding readers in quickly diagnosing and resolving similar issues.
Error Symptoms and Background
SSL_ERROR_RX_RECORD_TOO_LONG is a frequent error in Apache server SSL configurations, primarily appearing in Firefox browsers, with similar errors like ERR_SSL_PROTOCOL_ERROR in others. This error indicates that the received record during SSL handshake is too long, often due to improper server-side SSL setup. In practical cases, local reproduction may fail while remote users (e.g., in different countries) consistently encounter it, frequently linked to misconfigured network intermediaries such as proxy servers.
Error Cause Analysis
The core cause of this error is improper handling or routing of SSL traffic to the target secure server. Specific factors include: port misconfiguration, such as SSL not running on standard port 443; incorrect virtual host settings with DNS name mismatches in VirtualHost; multiple SSL certificates sharing the same IP address; expired or invalid SSL certificates; and local proxy server misconfigurations that disrupt the SSL handshake. For instance, in the Q&A case, the issue was traced to a client-side local proxy error rather than server configuration.
Detailed Solutions
For the SSL_ERROR_RX_RECORD_TOO_LONG error, the following solutions have been proven effective. First, ensure SSL operates on the standard port 443 by modifying Apache configuration files. For example, add the following lines in ports.conf or httpd.conf:
Listen 80
Listen 443 https
Second, inspect virtual host configurations. Many users report resolving the issue by changing the <VirtualHost> tag to _default_. For instance, modify <VirtualHost myserver.example.com:443> to <VirtualHost _default_:443>. This adjustment ensures all traffic on port 443 is correctly routed to the default SSL virtual host.
Additional Configuration Recommendations
Beyond the core solutions, other configuration details require attention. Ensure each SSL certificate uses a dedicated IP address to prevent conflicts. Verify SSL certificate validity to avoid errors from expiration. In IPv6-enabled environments, explicitly specifying IP addresses may help, such as adding Listen [::]:443 in configurations. Furthermore, configuring SSL cipher suites can enhance compatibility, for example using:
SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM:+SSLv3
For users of Apache modules, ensure the default-ssl site is enabled via the command a2ensite default-ssl, and set SSLEngine On in the virtual host.
Troubleshooting Steps
When encountering this error, follow these troubleshooting steps: first, test connections from different network environments to rule out local proxy issues; second, use tools like netstat -lpan | grep :443 to verify if port 443 is listening; then, check Apache error logs for detailed information; finally, apply the solutions incrementally, restarting the Apache service (e.g., systemctl restart apache2) after each change and testing the outcome. In the Q&A case, the user resolved the issue by modifying the VirtualHost configuration, highlighting the importance of configuration details.
Summary and Prevention
The SSL_ERROR_RX_RECORD_TOO_LONG error often stems from configuration oversights. Prevention can be achieved by standardizing port usage, correctly setting up virtual hosts, and regularly checking certificates. In practice, thoroughly test SSL configurations in development environments and use tools like SSL Labs to assess server security. Based on real cases and reference articles, this paper offers comprehensive and actionable guidance to help administrators swiftly restore services.