Troubleshooting Apache ‘ssl_error_rx_record_too_long’ on WSL2 Ubuntu (Port 443 Mismatch)

Resolve Apache 'ssl_error_rx_record_too_long' on WSL2 Ubuntu. This guide fixes SSL port 443 mismatches and misconfigurations, restoring HTTPS.

When accessing a web server running Apache on Windows Subsystem for Linux 2 (WSL2) Ubuntu, you might encounter the cryptic ssl_error_rx_record_too_long error in your web browser. This issue typically indicates that your browser, expecting a secure SSL/TLS handshake on port 443, received unencrypted HTTP traffic or an otherwise malformed or unexpected response from the server. This often points to a fundamental mismatch in how Apache is configured to serve content on port 443, or a conflict with another service.

Symptom & Error Signature

The primary symptom is that your browser fails to load a website served by Apache via HTTPS, presenting an error message similar to:

Firefox:

Secure Connection Failed

An error occurred during a connection to your-wsl2-site.local. SSL received a malformed or unsafe record.

Error code: SSL_ERROR_RX_RECORD_TOO_LONG

Chrome/Edge:

ERR_SSL_PROTOCOL_ERROR

This site can’t provide a secure connection
your-wsl2-site.local sent an invalid response.

While Apache's own error logs (/var/log/apache2/error.log) may not always directly log ssl_error_rx_record_too_long as it's a client-side (browser) error, they might show connection attempts or configuration warnings if the server itself is misconfigured or failing to start SSL.

Root Cause Analysis

The ssl_error_rx_record_too_long error signifies that the client (your browser) initiated an SSL/TLS handshake on a port (443) that was expecting it, but instead received a response that was too long or invalid for an SSL/TLS record. In simpler terms, it received non-SSL data on an SSL port.

Common underlying reasons for this scenario, especially within a WSL2 environment, include:

1. Apache Serving HTTP on Port 443: The most frequent cause is an Apache VirtualHost configured to serve plain HTTP traffic on port 443, rather than HTTPS. This happens if SSLEngine On is missing or incorrectly placed within the VirtualHost *:443 block.
2. Another Service Listening on Port 443:
   • WSL2 Internal: Another application or an incorrectly configured Apache instance within WSL2 is already bound to port 443.
   • Windows Host: A service on your Windows host machine (e.g., IIS, Skype, Docker Desktop, another web server, or even specific VPN software) is listening on port 443, intercepting the connection before it reaches Apache in WSL2.
3. Apache SSL Module Disabled or Misconfigured: The mod_ssl module might be disabled, or the SSL certificate and key paths in Apache's configuration are incorrect or inaccessible.
4. Incorrect Listen Directive: Apache's ports.conf or main configuration might not correctly specify Listen 443 https. While Listen 443 often implies SSL with mod_ssl enabled, explicit configuration is crucial.
5. Firewall Interference: Though less common for ssl_error_rx_record_too_long specifically, Windows Firewall or a Linux firewall (e.g., ufw in WSL2) could be blocking or mangling traffic to port 443.
6. WSL2 Networking Quirks: While WSL2 generally handles port forwarding seamlessly, intermittent issues or manual network configurations could lead to traffic misdirection.

Step-by-Step Resolution

Follow these steps to diagnose and resolve the ssl_error_rx_record_too_long error.

1. Verify Apache Status and Configuration

First, ensure Apache is running and its basic SSL configuration is correct.

1. Check Apache Service Status in WSL2: Open your WSL2 Ubuntu terminal and run:

   sudo systemctl status apache2
   

   Ensure the service is active (running). If not, start it:

   sudo systemctl start apache2
   

2. Test Apache Configuration Syntax: Always run a configuration test after making changes.

   sudo apachectl configtest
   

   You should see Syntax OK. Address any warnings or errors before proceeding.

3. Examine ports.conf: Verify that Apache is configured to listen on port 443.

   grep -E 'Listens+(80|443)' /etc/apache2/ports.conf
   

   You should see lines like:

   Listen 80
   Listen 443
   

4. Inspect SSL VirtualHost Configuration: Navigate to your Apache sites-enabled directory and examine the SSL configuration for your domain. This is typically found in files like 000-default-le-ssl.conf (for Certbot) or your_domain_ssl.conf.

   # Example: View default SSL config
   sudo nano /etc/apache2/sites-enabled/000-default-le-ssl.conf
   

   Within the <VirtualHost *:443> block, ensure that SSLEngine On is present and correctly configured, and that SSLCertificateFile, SSLCertificateKeyFile, and SSLCertificateChainFile (if applicable) point to valid certificate paths.

   Correct Example:

   <IfModule mod_ssl.c>
   <VirtualHost *:443>
       ServerName your-wsl2-site.local
       DocumentRoot /var/www/html
   
       SSLEngine On
       SSLCertificateFile /etc/letsencrypt/live/your-wsl2-site.local/fullchain.pem
       SSLCertificateKeyFile /etc/letsencrypt/live/your-wsl2-site.local/privkey.pem
       # SSLCertificateChainFile /etc/letsencrypt/live/your-wsl2-site.local/chain.pem (often included in fullchain.pem)
   
       # Other directives...
   
       ErrorLog ${APACHE_LOG_DIR}/ssl_error.log
       CustomLog ${APACHE_LOG_DIR}/ssl_access.log combined
   </VirtualHost>
   </IfModule>
   

   Incorrect (Common Error) Example (HTTP on 443):

   <VirtualHost *:443> # This VirtualHost expects HTTP if SSLEngine is missing!
       ServerName your-wsl2-site.local
       DocumentRoot /var/www/html
       # MISSING: SSLEngine On
       # MISSING: SSLCertificateFile, SSLCertificateKeyFile
   </VirtualHost>
   

   If you find a VirtualHost *:443 block without SSLEngine On and the SSL certificate directives, this is almost certainly your problem.

2. Confirm Port Availability & Usage

Determine if another process is already occupying port 443 on either your WSL2 instance or your Windows host.

1. Check Port 443 on WSL2:

   sudo lsof -i :443
   # OR
   sudo netstat -tuln | grep 443
   

   This will show which process (if any) is listening on port 443 within your WSL2 environment. If you see something other than apache2, identify it and stop it or reconfigure its port.

2. Check Port 443 on Windows Host: Open a Windows PowerShell or Command Prompt (as Administrator) and run:

   netstat -ano | findstr :443
   

   Look for a line showing 0.0.0.0:443 or [::]:443 with a LISTENING state. Note the PID (Process ID) on the far right. Then, find the process name using that PID:

   tasklist /svc /fi "PID eq <PID>"
   

   Replace <PID> with the actual PID.

   • Common culprits: http.sys (IIS, Web Deployment Agent), skype.exe, vmware-hostd.exe, docker.exe (Docker Desktop, if it's using a proxy), or even other local development servers.
   • If a Windows service is using port 443, you must either stop it, reconfigure it to use a different port, or disable it if it's not essential. For http.sys conflicts, you might need to use netsh http show urlacl and netsh http delete urlacl (with caution) or disable IIS entirely.

   Stopping or reconfiguring services on your Windows host can affect other applications. Proceed with caution and ensure you understand the implications.

3. Inspect Apache SSL Module and Certificates

1. Ensure mod_ssl is Enabled: The SSL module must be enabled for Apache to handle HTTPS.

   sudo a2enmod ssl
   

   If it was not enabled, run this command and then reload Apache (sudo systemctl reload apache2).

2. Verify Certificate Permissions and Paths: Double-check that the SSLCertificateFile and SSLCertificateKeyFile paths in your VirtualHost configuration are correct and that Apache has read permissions.

   sudo ls -l /etc/letsencrypt/live/your-wsl2-site.local/fullchain.pem
   sudo ls -l /etc/letsencrypt/live/your-wsl2-site.local/privkey.pem
   

   Ensure the files exist and have appropriate permissions (e.g., 644 for fullchain, 640 or 400 for privkey, often owned by root:root with group read for ssl-cert or www-data).

4. WSL2 Networking and Windows Firewall

While WSL2 typically handles port exposure automatically, ensure no explicit blocking is occurring.

1. Windows Firewall: The default Windows Firewall configuration for WSL2 usually allows traffic. However, if you've implemented custom rules or use third-party firewalls, they might be interfering.

   • Temporarily disable the Windows Firewall (for testing ONLY, and re-enable immediately after) to see if it resolves the issue.
   • A safer approach: Create an inbound rule to explicitly allow connections on port 443 for wsl.exe or vmmem.exe.

   Do not leave your firewall disabled in a production environment. Only temporarily disable it for testing and re-enable it immediately after. If it fixes the issue, create a specific rule for port 443.

5. Restart Apache and Test

After making any changes, restart Apache and thoroughly test your site.

1. Reload or Restart Apache:

   sudo systemctl restart apache2
   

2. Test from within WSL2: Use curl to test the HTTPS connection from inside your WSL2 terminal.

   curl -v https://localhost/
   # OR if using a specific hostname
   curl -v https://your-wsl2-site.local/
   

   Look for a successful SSL handshake (e.g., "SSL connection using TLSv1.3", "Certificate chain verified") and an HTTP 200 OK response. If curl itself gives an SSL error, inspect its output carefully.

3. Test from Windows Host:

   • Open your web browser on Windows and navigate to https://localhost/ or https://your-wsl2-site.local/ (if you have configured your Windows hosts file for this domain).
   • Ensure the website loads securely with a padlock icon.

By systematically working through these steps, particularly focusing on the SSLEngine On directive within your VirtualHost *:443 block and checking for port conflicts on both WSL2 and Windows, you should be able to resolve the ssl_error_rx_record_too_long error.