Ssl_error_rx_record_too_long

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: suitecrm.pleissrealtygroup.com

I ran this command: sudo certbot install --cert-name suitecrm.pleissrealtygroup.com

It produced this output:

Screenshot from 2023-09-19 17-24-48
Screenshot from 2023-09-19 17-24-481267×83 14.7 KB

Assuming everything had installed, I navigated to the URL via HTTPS and got the error in the title.

My web server is (include version): Apache 2.4

The operating system my web server runs on is (include version): Debian 12

My hosting provider, if applicable, is: AWS EC2 Instance

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): 2.1.0

Additional Info:

So I had tried to run certbot to generate a certificate for Apache2, and it failed because I had forgot to change the ServerName -- then I ran the command above to install the certificate as recommended by the error message from the first run of certbot.

Everything looks okay except for this error in Firefox v117.

The install appears to have been successful, and I noticed that there are new .conf files in sites-available.

Everything was setup automatically by certbot after I configured the initial vhost for the CRM.

Let me know if you need any more info. I can provide the .conf files created by certbot if need be, or anything else that might be related.

2

Hi @julianapleiss, and welcome to the LE community forum :slight_smile:

Is this your first secure web site?

Can you show the complete error message/log entry?

Have you verified that Apache is doing what you expect?
[hint: use sudo apachectl -t -D DUMP_VHOSTS]

4 Likes
3

The website is listening on port 443, normally used for HTTPS, but is listening plaintext HTTP. Something is wrong with the Apache configuration.

$ curl http://suitecrm.pleissrealtygroup.com:443

<!DOCTYPE html P....
          <p>
                This is the default welcome page used to test the correct 
                operation of the Apache2 server after installation on Debian systems.
5 Likes
4

Thanks for the welcome!

I've used certbot to setup a few websites in the past, but I basically just followed the instructions until I ran into this error.

Which log do you need?

This is the result of that command:
AH00112: Warning: DocumentRoot [/var/www/html/suitecrm/public] does not exist
AH00112: Warning: DocumentRoot [/var/www/html/suitecrm/public] does not exist
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using fe80::4ca:a0ff:fe04:64b7%enX0. Set the 'ServerName' directive globally to suppress this message
VirtualHost configuration:
54.151.55.248:443 suitecrm.pleissrealtygroup.com (/etc/apache2/sites-enabled/suitecrm-le-ssl.conf:2)
54.151.55.248:80 suitecrm.pleissrealtygroup.com (/etc/apache2/sites-enabled/suitecrm.conf:1)
*:80 fe80::4ca:a0ff:fe04:64b7%enX0 (/etc/apache2/sites-enabled/000-default.conf:1)

I haven't actually moved the files to the document root yet, so that's why the first couple errors appear. AFAIK that shouldn't be affecting anything and I don't want to pass credentials over plaintext so I was trying to get SSL working first.

Anyway, I wasn't sure how/whether to disable the default site, and I had to specify the IP because of some error I had ran into during the install last time.. everything looks fine to me, but maybe I'm missing something?

I find it interesting that the default site is being served via IPv6 though.

1 Like
5

I'm confused because I specified apache when I first ran certbot, so the configuration should have been handled by certbot shouldn't it have?

This is the default configuration after running the commands in my first post. I know that it is an issue with vhost configuration usually based on my internet searches, but I don't know how to resolve it in this particular situation, or if that's what is actually wrong.

Edit: Okay, something is wrong here. That's the default site being served over HTTP for some reason, even though there's a new .conf file for it in the directory.

I can hardly make sense of the .conf files, but I've been able to identify that they do some kind of rewrite that I don't understand, and that paths to the certificates are indeed in place.

These are the configuration files in sites-available now:

image
image788×605 22.6 KB

6

Okay, so it looks like I was able to get it working by running 'sudo a2ensite default-ssl.conf', and now it shows a self-signed certificate and asks to grant a security exception.. because the site was not enabled it was redirecting to HTTP.

For some reason, because the default site is enabled (I think I usually disable it but read somewhere it was not recommended), it was redirecting to the default site.

I'm going to create the DocumentRoot file structure and then I'll test and see if it serves those folders over SSL.

7

Okay, I've moved the files to the DocumentRoot, and disabled 000-default.conf and default-ssl.conf, and now I am getting the same error.

Since those are disabled, it should only be serving the proper DocumentRoot, but the error was not resolved so I've unmarked the topic as solved.

I'm not sure what could be wrong with Apache2. I've barely changed anything, except to create a basic suitecrm.conf file, then ran certbot to generate (and separately to install) the certificates.

Either I've done something wrong or something is wrong with the default configuration, but I'm unsure as to which at the moment. I've gone through the files and they don't look like the .conf files that I'm used to for Apache2, but everything suggests this is the source of the problem.

9

Here's a screenshot of the error:

Screenshot from 2023-09-19 19-06-46
Screenshot from 2023-09-19 19-06-461012×838 45.7 KB

10

And here's the .conf file after certbot changed it:

Screenshot from 2023-09-19 19-09-41
Screenshot from 2023-09-19 19-09-41788×605 64.9 KB

11

That's problematic.
It means that some vhost(s) aren't being served.

IPs should not be used when defining vhosts.

It serves the sites alphabeticcally.
That just means that the file name 000-default.conf is the first in that line.
[and that no vhost has the added _default_ setting in use]

Please show the file:

3 Likes
13

I believe they're being served now. I hadn't actually setup the directories yet, and I can now view the files over HTTP.

Here's the suitecrm.conf file:

Screenshot from 2023-09-19 19-09-41
Screenshot from 2023-09-19 19-09-41788×605 64.9 KB

I forget why but I was having issues getting the installer (for SuiteCRM) to run before without specifying the IP address, but I can always change it back to wildcards.

I've used IP addresses to serve HTTP over a Private IP before (only accessible via VPN), and I kind of thought that was just a standard thing but maybe I'm wrong.

14

That can work for private IPs - but that is using a public IP.

The complaint is about the suitecrm/public folder path not existing:

It is then also trying to set permissions on a path that doesn't exist:
image

Step #1: Create that path.
Step #2: Remove IP from VirtualHost definition.
Step #3: Test it all OR, at least, whatever you think might not be working.

4 Likes
15

At this time browsing to http://suitecrm.pleissrealtygroup.com gives me a directory listing "Index of /" with the suitecrm top directory, which can be traversed, listed, and all files viewed. Please put some kind of index.html file in you documentroot as this is a serious security risk.

1 Like
16

You're just browsing publicly available code at this point. It's all FOSS and source is available elsewhere. The CRM has not been installed and the database has not been populated with data -- that's where client data will eventually live, and why I haven't ran the install script yet, because I need SSL working before I try to enter database credentials.

I deleted the default index.html but I guess I could throw a "Hello, World!" in there or something.. it was populating from /var/www/html/index.html though which was not the intended behavior.

17

I created the path, set permissions, and the only thing left to do is run the install script, which I refuse to do over HTTP.

I'll remove the IP and restart Apache2.

Edit: It's now serving over HTTPS!

2 Likes
18

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.