Troubleshooting Apache: ssl_error_rx_record_too_long on Ubuntu 22.04 LTS

Fix Apache 'ssl_error_rx_record_too_long' on Ubuntu 22.04 LTS when SSL port 443 is misconfigured or another service is listening.

When users attempt to access your website via HTTPS, they might encounter a dreaded "ssl_error_rx_record_too_long" error in their browser. This typically indicates a critical misconfiguration where the server, specifically Apache on port 443, is sending plain HTTP data (or other non-SSL data) when the client (browser) expects an SSL/TLS handshake. Essentially, the browser is talking SSL, but the server is not, leading to a protocol mismatch. This guide will walk you through diagnosing and resolving this issue on an Ubuntu 22.04 LTS system running Apache 2.4.

Symptom & Error Signature

Users attempting to reach your site via https://yourdomain.com will be presented with a browser error page instead of your website content.

Browser Error Examples:

• Firefox:

  SSL_ERROR_RX_RECORD_TOO_LONG
  The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
  Please contact the website owners to inform them of this problem.
  

• Google Chrome:

  ERR_SSL_PROTOCOL_ERROR
  This site can't provide a secure connection
  yourdomain.com sent an invalid response.
  

Server-Side Log Entries (Less common for this specific error, but can provide clues):

While this error is primarily client-side, an Apache error.log (usually located at /var/log/apache2/error.log) might show errors related to SSL certificate loading, VirtualHost parsing, or Apache failing to start if the configuration is severely broken.

# Example of potential Apache error log entries indicating SSL issues
[Thu Oct 03 10:00:00.123456 2026] [ssl:emerg] [pid 12345:tid 1234567890] AH02562: Failed to configure at least one certificate and key for yourdomain.com:443
[Thu Oct 03 10:00:00.123456 2026] [ssl:emerg] [pid 12345:tid 1234567890] SSL Library Error: error:0900006E:PEM routines::NO START LINE
[Thu Oct 03 10:00:00.123456 2026] [ssl:emerg] [pid 12345:tid 1234567890] AH02312: Fatal error initialising mod_ssl, exiting.

Root Cause Analysis

The "ssl_error_rx_record_too_long" error occurs when a client initiates a TLS handshake on port 443, but the server responds with data that is not a valid TLS record. The common underlying reasons for this behavior on an Apache server are:

1. Misconfigured Apache SSL Virtual Host:

   • Missing SSLEngine On: The most frequent cause. An Apache Virtual Host configured to listen on port 443 (<VirtualHost *:443>) is missing the SSLEngine On directive, causing Apache to serve plain HTTP traffic on the SSL port.
   • Incorrect SSL Certificate Directives: Incorrect paths for SSLCertificateFile, SSLCertificateKeyFile, or SSLCertificateChainFile, or files with incorrect permissions, can prevent Apache from initializing SSL correctly. This often results in Apache either failing to start or falling back to a non-SSL default.
   • Conflicting Virtual Hosts: A default or wildcard Virtual Host that is configured for HTTP might inadvertently catch traffic on port 443 due to a configuration oversight.

2. Conflicting Service Listening on Port 443:

   • Another web server (e.g., Nginx, Caddy, a second Apache instance, a development server like Node.js, or a Docker container) is running on the same server and has bound itself to port 443 before Apache. If this conflicting service is not configured for SSL/TLS, it will send non-SSL data, leading to the error.

3. Corrupt or Invalid SSL Certificate/Key Files:

   • While Apache's configtest often catches syntax errors, a certificate or key file that is malformed, expired, or doesn't match the key can cause SSL initialization issues.

4. Firewall or Network Proxy Issues (Less Common for this specific error):

   • Though less likely to directly cause ssl_error_rx_record_too_long from the server itself, a misconfigured reverse proxy or load balancer could be forwarding HTTP to Apache on port 443, or stripping SSL before it reaches Apache. This guide will focus on direct Apache server issues.

Step-by-Step Resolution

Follow these steps meticulously to diagnose and resolve the "ssl_error_rx_record_too_long" error.

1. Identify Services Listening on Port 443

First, determine definitively what process is listening on port 443.

sudo ss -tulpn | grep 443

Expected output if Apache is correctly listening for HTTPS:

tcp    LISTEN     0      511      0.0.0.0:443            0.0.0.0:*          users:(("apache2",pid=12345,fd=6))
tcp    LISTEN     0      511         [::]:443               [::]:*          users:(("apache2",pid=12345,fd=7))

If you see a different process (e.g., Nginx, or an unknown PID) or no process at all, then Apache is not properly bound to 443 or is being preempted.

# Example if Nginx is listening
tcp    LISTEN     0      128      0.0.0.0:443            0.0.0.0:*          users:(("nginx",pid=54321,fd=6))

2. Verify Apache SSL Module and Global Configuration

Ensure the SSL module is enabled and Apache's global ports.conf is correctly configured.

1. Enable mod_ssl:

   sudo a2enmod ssl
   sudo systemctl restart apache2
   

   If mod_ssl was not enabled, enabling it and restarting Apache might fix the issue immediately if your VirtualHost was otherwise correct.

2. Check ports.conf: Open the global Apache ports configuration file:

   sudo nano /etc/apache2/ports.conf
   

   Ensure that Listen 443 is present and uncommented:

   Listen 80
   Listen 443
   
   <IfModule ssl_module>
           Listen 443
   </IfModule>
   
   <IfModule mod_gnutls.c>
           Listen 443
   </IfModule>
   

3. Inspect SSL Parameters (optional but good practice): Review your SSL configuration parameters file, usually /etc/apache2/conf-available/ssl-params.conf (if you use Mozilla SSL Generator recommendations) or /etc/apache2/mods-available/ssl.conf.

   sudo nano /etc/apache2/conf-available/ssl-params.conf
   

   Ensure no SSLEngine On directives are placed globally outside of a specific <VirtualHost> context, as this can lead to unexpected behavior.

3. Inspect Apache Virtual Host Configuration for SSL

This is the most critical step. A common mistake is a missing SSLEngine On directive within the SSL Virtual Host.

1. Navigate to sites-enabled:

   cd /etc/apache2/sites-enabled/
   

2. Examine your SSL Virtual Host file(s): Identify the configuration file for your domain's SSL (e.g., yourdomain.com-le-ssl.conf or default-ssl.conf).

   sudo nano yourdomain.com-le-ssl.conf
   

3. Verify Key Directives: Inside your <VirtualHost *:443> block, ensure the following directives are correctly set:

   <IfModule mod_ssl.c>
   <VirtualHost *:443>
       ServerName yourdomain.com
       ServerAlias www.yourdomain.com
       DocumentRoot /var/www/yourdomain.com/html
   
       # CRITICAL: This directive MUST be present to enable SSL for this VirtualHost.
       SSLEngine On
   
       # Specify the paths to your SSL certificate, key, and chain files.
       # Ensure these paths are correct and the files exist.
       SSLCertificateFile /etc/letsencrypt/live/yourdomain.com/fullchain.pem
       SSLCertificateKeyFile /etc/letsencrypt/live/yourdomain.com/privkey.pem
       # SSLCertificateChainFile /etc/letsencrypt/live/yourdomain.com/chain.pem # Often included in fullchain.pem
   
       # Other SSL/TLS specific directives (e.g., protocols, ciphers, HSTS)
       # Include your SSL parameters here, often from /etc/apache2/conf-available/ssl-params.conf
       Include /etc/apache2/conf-available/ssl-params.conf
   
       ErrorLog ${APACHE_LOG_DIR}/yourdomain.com_error.log
       CustomLog ${APACHE_LOG_DIR}/yourdomain.com_access.log combined
   
       # Add other necessary directives like Directory, ProxyPass, etc.
   </VirtualHost>
   </IfModule>
   

   Double-check the paths for SSLCertificateFile and SSLCertificateKeyFile. Typo or incorrect paths are a common source of SSL initialization failures. Ensure there is no other <VirtualHost *:443> block that could conflict or lack SSLEngine On.

4. Test Apache Configuration Syntax

After making any changes to configuration files, always test Apache's syntax before restarting.

sudo apache2ctl configtest

or

sudo apache2 -t

Expected output:

Syntax OK

If you receive any errors, address them immediately. The output will usually point to the problematic file and line number.

5. Restart Apache Service

If the syntax test passes, restart Apache to apply the changes.

sudo systemctl restart apache2
sudo systemctl status apache2

Verify that Apache is running without errors. If it fails to start, check the error.log (/var/log/apache2/error.log) for detailed reasons.

6. Open Firewall Port 443 (UFW)

Ensure your firewall is not blocking incoming connections on port 443. Ubuntu often uses UFW (Uncomplicated Firewall).

1. Check UFW status:

   sudo ufw status
   

2. Allow HTTPS traffic: If port 443 is not allowed, enable it.

   sudo ufw allow 'Apache Full'
   # Or more specifically:
   sudo ufw allow 443/tcp
   

   Reload UFW if you made changes:

   sudo ufw reload
   

7. Address Conflicting Services (if found in Step 1)

If Step 1 revealed another service listening on port 443 (e.g., Nginx, another Apache instance), you have several options:

1. Stop the conflicting service:

   sudo systemctl stop conflicting-service-name
   sudo systemctl disable conflicting-service-name # Prevent it from starting on boot
   

   Then, restart Apache (sudo systemctl restart apache2) and check.

2. Reconfigure the conflicting service: If you need both services, reconfigure the other service to listen on a different port (e.g., 8443) or use a reverse proxy to manage traffic. This is a more complex setup beyond the scope of this guide but often involves setting up a proxy.

3. Uninstall the conflicting service: If the service is no longer needed.

   sudo apt remove conflicting-service-name
   

8. Verify Permissions for SSL Certificate and Key Files

Incorrect file permissions can prevent Apache from reading your SSL certificate and key files, leading to startup failures or SSL initialization problems.

# Example for Let's Encrypt files
# Certificate file should be readable by all, but owned by root
sudo chmod 644 /etc/letsencrypt/live/yourdomain.com/fullchain.pem
sudo chown root:root /etc/letsencrypt/live/yourdomain.com/fullchain.pem

# Private key file should be highly restricted (readable only by root)
sudo chmod 400 /etc/letsencrypt/live/yourdomain.com/privkey.pem
sudo chown root:root /etc/letsencrypt/live/yourdomain.com/privkey.pem

The private key must be kept secure. chmod 400 ensures only the root user can read it. Apache runs as root initially to bind to privileged ports, then drops privileges to the www-data user (by default on Ubuntu) for serving content. During the initial root phase, it reads the private key.

After any permission changes, restart Apache.

By systematically going through these steps, you should be able to pinpoint the exact cause of the "ssl_error_rx_record_too_long" error and restore secure HTTPS access to your Apache-hosted website on Ubuntu 22.04 LTS.