Join Log in
Score:3
Simone avatar Server

SSL_ERROR_RX_RECORD_TOO_LONG after installing Certbot on Apache2

pl flag
Simone

I'm trying to set up a web server on a raspberry pi, it's running a debian based system.

I installed and set up apache (following this guide), set up port forwaring on my router and created 3 html only websites to test things.

Since I only have one domain I wanted to try and use virtual hosts with subdomains: main domain had ServerName domain.com and ServerAlias www.domain.com, the other 2 were ServerName x/y.domain.com ServerAlias www.x/y.domain.com. Up to this point (http only) everything was working, I could reliably reach the server with the domains specified in their name / alias.

I then set out to use install certificates to enable https. I found out about certbot / letsencrypt and followed this guide. On step 7 when I ran: sudo certbot --apache I decided to get a certificate for all the enabled domains (6, the main name and alias for each of the 3 prevoiusly mentioned). The output was successful but when I tried connecting to my main domain (domain.com) I could not reach it, not with http nor with https. (I get the error: To make things simpler I disabled my other 2 sites (that were now 4 because certbot created and enabled the https versions), I kept only my main domain on http / https.

I tried removing the certbot certificates and getting new ones following these commands. Another successful output

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/bravewonderer.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/bravewonderer.com/privkey.pem
This certificate expires on 2023-01-18.

I manually checked the certificate files and they exist and have data inside them.

But once again when I try to visit https://bravewonderer.com or http://www.bravewonderer.com I just get Secure Connection Failed ... Error code: SSL_ERROR_RX_RECORD_TOO_LONG

These are the full configuration files for the http and https version of the website, including the file that certbot generated and includes:

# /etc/apache2/sites-available/head.conf
<VirtualHost *:80>
        # The ServerName directive sets the request scheme, hostname and port that
        # the server uses to identify itself. This is used when creating
        # redirection URLs. In the context of virtual hosts, the ServerName
        # specifies what hostname must appear in the request's Host: header to
        # match this virtual host. For the default virtual host (this file) this
        # value is not decisive as it is used as a last resort host regardless.
        # However, you must set it for any further virtual host explicitly.
        #ServerName www.example.com

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/head/public_html

        ServerName bravewonderer.com
        ServerAlias www.bravewonderer.com

        # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
        # error, crit, alert, emerg.
        # It is also possible to configure the loglevel for particular
        # modules, e.g.
        #LogLevel info ssl:warn

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

        # For most configuration files from conf-available/, which are
        # enabled or disabled at a global level, it is possible to
        # include a line for only one particular virtual host. For example the
        # following line enables the CGI configuration for this host only
        # after it has been globally disabled with "a2disconf".
        #Include conf-available/serve-cgi-bin.conf
RewriteEngine on
RewriteCond %{SERVER_NAME} =www.bravewonderer.com [OR]
RewriteCond %{SERVER_NAME} =bravewonderer.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
---------------------------------------------

# /etc/apache2/sites-available/head-le-ssl.conf
<IfModule mod_ssl.c>
<VirtualHost *:443>
        # The ServerName directive sets the request scheme, hostname and port that
        # the server uses to identify itself. This is used when creating
        # redirection URLs. In the context of virtual hosts, the ServerName
        # specifies what hostname must appear in the request's Host: header to
        # match this virtual host. For the default virtual host (this file) this
        # value is not decisive as it is used as a last resort host regardless.
        # However, you must set it for any further virtual host explicitly.
        #ServerName www.example.com

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/head/public_html

        ServerName bravewonderer.com
        ServerAlias www.bravewonderer.com

        # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
        # error, crit, alert, emerg.
        # It is also possible to configure the loglevel for particular
        # modules, e.g.
        #LogLevel info ssl:warn

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

        # For most configuration files from conf-available/, which are
        # enabled or disabled at a global level, it is possible to
        # include a line for only one particular virtual host. For example the
        # following line enables the CGI configuration for this host only
        # after it has been globally disabled with "a2disconf".
        #Include conf-available/serve-cgi-bin.conf


Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/bravewonderer.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/bravewonderer.com/privkey.pem
</VirtualHost>
</IfModule>
---------------------------------------------

# /etc/letsencrypt/options-ssl-apache.conf

# This file contains important security parameters. If you modify this file
# manually, Certbot will be unable to automatically provide future security
# updates. Instead, Certbot will print and log an error message with a path to
# the up-to-date file that you will need to refer to when manually updating
# this file. Contents are based on https://ssl-config.mozilla.org

SSLEngine on

# Intermediate configuration, tweak to your needs
SSLProtocol             all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder     on
#SSLHonorCipherOrder     off
SSLSessionTickets       off

SSLOptions +StrictRequire

# Add vhost name to log entries:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" vhost_combined
LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost_common

If someone could point in me in the right direction it'd be very helpful.

Edit. Some additional notes:

  • sudo a2enmod ssl tells me that ssl is already enabled
  • When I try connecting to the server through my pc using curl http://bravewonderer.com:443 I get 301 Moved Permanently, document has moved to https://bravewonderer.com, from my limited understanding it would seem that:
    1. the server is trying to redirect me to the https version but
    2. it ends up not being accessible because of the error

While trying to troubleshoot I also ran curl -v https://bravewonderer.com output is

*   Trying 2.230.32.65:443...
* Connected to bravewonderer.com (2.230.32.65) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* (5454) (IN), , Unknown (72):
* error:0A00010B:SSL routines::wrong version number
* Closing connection 0
curl: (35) error:0A00010B:SSL routines::wrong version number
707
2 + 2
drookie avatar
za flag
drookie
`http://bravewonderer.com:443` is nonsense. tcp/443 should be listened by something that has TLS support. That's the root cause of your problems. And `SSL_ERROR_RX_RECORD_TOO_LONG` is most probably an error when TLS is requested on a plain HTTP connection. Typical.
1
Reply
Simone avatar
pl flag
Simone
Hi, I've updated the post with the output of `curl -v` on the https route as well. The command you refer to is just something I found mentioned somewhere online in an attempt to troubleshoot the error I found while visiting the site through the htttps link.
0
Reply
Score:3
vidarlo avatar Server
ar flag
vidarlo

You don't run TLS on your :443 vhost:

$ curl -I http://bravewonderer.com:443
HTTP/1.1 301 Moved Permanently
Date: Thu, 20 Oct 2022 12:18:07 GMT
Server: Apache/2.4.54 (Debian)
Location: https://bravewonderer.com/
Content-Type: text/html; charset=iso-8859-1

This should fail, as I try to talk HTTP to a HTTPS server. It doesn't. Your server is not properly configured.

+ 6
Simone avatar
pl flag
Simone
HI, thanks for the response. In the post I share my config for what's supposed to be the https site (which was created by certbot). From what I understand it should filter https traffic by the `<VirtualHost *:443>` tag (different from the one in the http version which is `<VirtualHost *:80>`) and then uses the same ServerName, ServerAlias, DocumentRoot. It just includes the certificates and another config file from letsencrypt itself. Do you see any red flag?
0
Reply
vidarlo avatar
ar flag
vidarlo
No. You need a few more directives. The [documentation has a minimal example](https://httpd.apache.org/docs/2.4/ssl/ssl_howto.html). Start from that.
0
Reply
Simone avatar
pl flag
Simone
I reduced the config file to the minumal example from the docs for my version ([2.5](https://httpd.apache.org/docs/trunk/ssl/ssl_howto.html)). I plugged in my own server name and paths, and removed the listen directive since it's already present in `ports.conf` which is included in the main `apache2.conf`. I disabled the website listening for traffic on `<VirtualHost *:80>` so only the https one is enabled. After all of this if I just try `curl www.bravewonderer.com` I get results back. There should be no listener active for connections outside port 443. Quite confused...
0
Reply
Simone avatar
pl flag
Simone
Update: I removed the listener on port 80 all together now both http and https request fail with `Connection refused`. Even if specifying port 443
0
Reply
vidarlo avatar
ar flag
vidarlo
Why did you do that? Start with a minimum configuration for your TLS vhost. Build from that.
0
Reply
Simone avatar
pl flag
Simone
I just posted an answer, somehow I think I had misconfigured the port forwarding on my router and since before implementing https it wasn't giving any problem I stubbornly searched for the issue elsewhere.
0
Reply
Score:0
Simone avatar Server
pl flag
Simone

I solved the issue, short answer: my router port forwarding configuration was not correct and I think it was mapping traffic from port 443 to port 80.

Longer answer: In an attempt to troubleshoot the issue I started removing piece by piece everything that was unnecessary. I noticed that after removing any listener on port 80 and leaving only the one on port 443, requests to port 80 were still going through (and those to 443 were failing). I'm not sure how it happened but my router was switching traffic for port 443 to port 80 and vice versa.

+ 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.