Fixing Apache ssl_error_rx_record_too_long on Debian 12 (Bookworm) for SSL Port 443 Mismatch

Resolve Apache's ssl_error_rx_record_too_long on Debian 12 Bookworm caused by a misconfigured SSL port 443, ensuring proper HTTPS delivery.

When navigating to your website over HTTPS, encountering the ssl_error_rx_record_too_long error indicates that your browser received an unexpected, non-SSL response on a port where it anticipated a secure connection. On Debian 12 Bookworm with Apache, this usually points to a critical misconfiguration where your web server is sending unencrypted HTTP content over port 443, which is reserved for secure HTTPS traffic. This guide provides a detailed, step-by-step resolution for this common issue.

Symptom & Error Signature

Users attempting to access your site via https://yourdomain.com will see a browser error message. While the exact wording varies, the core message points to an SSL record length issue.

Typical Browser Error (e.g., Firefox):

Secure Connection Failed

An error occurred during a connection to yourdomain.com. SSL received a record that exceeded the maximum permissible length.

Error code: 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.

Potential Apache Error Log Snippets (less common for this specific client-side error, but good to check /var/log/apache2/error.log for related configuration parsing issues):

[timestamp] [mpm_event:notice] [pid XXXX:tid XXXXX] AH00489: Apache/2.4.57 (Debian) OpenSSL/3.0.11 configured -- resuming normal operations
[timestamp] [core:warn] [pid YYYY:tid YYYYY] AH00098: pid file /var/run/apache2/apache2.pid overwritten -- system crash or long-running process?

(These are general operational logs, the ssl_error_rx_record_too_long error is primarily a client-side observation of a misconfigured server response.)

Root Cause Analysis

The ssl_error_rx_record_too_long error specifically means the client (your browser) initiated an SSL/TLS handshake on port 443 but received data that was not a valid SSL/TLS record and was also longer than an SSL record should typically be. This most frequently occurs when:

1. Apache is serving HTTP content on port 443: This is the most prevalent cause. An Apache Virtual Host or a default configuration intended for HTTP (unencrypted) traffic is incorrectly configured to listen and respond on port 443. This means Apache is attempting to send plain HTTP headers and HTML over the port where the browser expects encrypted TLS packets.
2. Missing SSLEngine On directive: An SSL-enabled Virtual Host for port 443 might be missing the crucial SSLEngine On directive, preventing Apache from initiating the SSL/TLS handshake.
3. Incorrect Listen directive placement: The Listen 443 directive in /etc/apache2/ports.conf or an included file might not be correctly associated with an IfModule mod_ssl.c block, or it might be duplicated, leading to unexpected behavior.
4. Another service is listening on port 443: Although less common if Apache is intended to run, another service (e.g., Nginx, a reverse proxy, or a custom application) might be inadvertently or maliciously binding to port 443 and serving non-SSL content before Apache gets a chance.
5. Corrupted or missing mod_ssl: While rare, if the mod_ssl module is not enabled or corrupted, Apache won't be able to handle SSL/TLS traffic correctly on port 443.

Step-by-Step Resolution

Follow these steps to diagnose and resolve the ssl_error_rx_record_too_long error on your Debian 12 Apache server.

1. Verify Apache's mod_ssl Module

Ensure that the mod_ssl module is enabled, as it's essential for handling HTTPS traffic.

sudo a2enmod ssl
sudo systemctl restart apache2

2. Identify the Service Listening on Port 443

Confirm that Apache is indeed the service listening on port 443 and that no other rogue process has taken over.

sudo netstat -tulnp | grep 443

Expected Output Example:

tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      1234/apache2

If you see a different process or no apache2 entry, investigate that process or check your Apache logs for binding errors.

3. Inspect /etc/apache2/ports.conf

This file dictates which ports Apache listens on. Ensure Listen 443 is correctly placed within an IfModule mod_ssl.c block.

sudo nano /etc/apache2/ports.conf

Look for a section similar to this:

# If you add NameVirtualHost to this configuration file, you will have to
# restart Apache to utilize it.
#
# NameVirtualHost *:80
#
Listen 80

<IfModule mod_ssl.c>
        Listen 443
</IfModule>

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

• Ensure Listen 443 is present.
• Ensure it's within the <IfModule mod_ssl.c> block or at least not outside of it without other specific SSL directives, to prevent it from being treated as a generic HTTP port by default.
• Remove any duplicate Listen 443 directives.

4. Review Apache Virtual Host Configurations

This is the most critical step. The error almost always stems from an incorrect Virtual Host configuration for port 443.

First, navigate to your Apache sites-enabled directory:

cd /etc/apache2/sites-enabled/

Then, inspect all Virtual Host files, paying close attention to any configured for port 443. For typical setups, your SSL configuration might be in a file like yourdomain.com-le-ssl.conf or default-ssl.conf.

# Example: Inspect all files for port 443 references
grep -r "VirtualHost *:443" .
grep -r "VirtualHost _default_:443" .

Open the relevant configuration file(s) for editing. Let's assume you have a file named yourdomain.com-le-ssl.conf.

sudo nano yourdomain.com-le-ssl.conf

Look for the following common misconfigurations:

• Missing SSLEngine On: Every Virtual Host block listening on port 443 must have SSLEngine On.
• Missing or Incorrect SSLCertificateFile / SSLCertificateKeyFile: These directives point to your SSL certificate and private key. Ensure their paths are correct and the files exist and are readable by Apache.
• HTTP-only directives in an SSL block: Ensure you are not serving non-SSL specific content or redirecting HTTP to HTTP within the 443 vhost.

Correct SSL Virtual Host Example:

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerName yourdomain.com
    ServerAlias www.yourdomain.com
    DocumentRoot /var/www/yourdomain.com/html

    ErrorLog ${APACHE_LOG_DIR}/yourdomain.com-error.log
    CustomLog ${APACHE_LOG_DIR}/yourdomain.com-access.log combined

    SSLEngine On
    SSLCertificateFile /etc/letsencrypt/live/yourdomain.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/yourdomain.com/privkey.pem
    Include /etc/letsencrypt/options-ssl-apache.conf

    # Other directives like ProxyPass, RewriteRules, etc.
    # ...

</VirtualHost>
</IfModule>

Verify that no non-SSL VirtualHost *:443 blocks exist. If you find a VirtualHost *:443 without SSLEngine On, it is the most likely culprit. Either remove it, or convert it into a proper SSL Virtual Host by adding SSLEngine On and the certificate directives.

Common Mistake: Duplicating an HTTP Virtual Host for HTTPS without modification: A common error is copying an *:80 vhost and changing it to *:443 but forgetting to add SSLEngine On and the certificate directives. This will cause Apache to serve plain HTTP over port 443.

5. Test Apache Configuration and Restart

After making any changes, always test your Apache configuration for syntax errors before restarting.

sudo apache2ctl configtest

You should see Syntax OK. If not, review the error messages and correct the syntax in the specified files.

Once the configuration is Syntax OK, restart Apache:

sudo systemctl restart apache2

If apache2ctl configtest reports errors, do not restart Apache until they are resolved. A broken configuration can prevent Apache from starting, making your website unavailable.

6. Verify Firewall Settings

While not the direct cause of ssl_error_rx_record_too_long (which implies a connection was made), ensure your firewall (e.g., UFW) allows traffic on port 443.

sudo ufw status verbose

If port 443 is not listed as ALLOWed, enable it:

sudo ufw allow 'Apache Full' # or sudo ufw allow 443/tcp
sudo ufw enable

7. Clear Browser Cache and Test

Sometimes browsers cache old connection information. Clear your browser's cache or try accessing the site in an incognito/private window to ensure you're getting a fresh connection attempt.

Navigate to https://yourdomain.com and confirm the site loads securely. You should see the padlock icon in your browser's address bar.

By carefully following these steps, you should be able to identify and rectify the Apache configuration issue causing the ssl_error_rx_record_too_long error on your Debian 12 Bookworm server, restoring proper HTTPS functionality.