HTTPS Traffic throws back a 404 after installing SSL certificate

A hearty HELLO! and a thankful tip of the hat to the Let’s Encrypt community,

I would like to start out by thanking all of those who are involved in making this service available to the public. Your work is greatly appreciated!

I am running a LAMP server on DigitalOcean, with virtual hosts setup to run multiple domains via Apache.

I’ve successfully gotten the Let’s Encrypt certbot to function smoothly on most of the sites that I’m running upon my VPS, with the exception of one tricky domain. This particular site is able serve up standard HTTP pages, but the secure connections throw back a 404 in my web-browser.

My domain is:
excessive.energy

My server is running Ubuntu 18.04, with certbot 0.23.0 installed, and I have root access from within a remote shell.

I ran this command:

sudo certbot run -a webroot -i apache -w /var/www/excessive.energy/public_html -d excessive.energy -d www.excessive.energy --debug-challenges

I felt it necessary to input the above command because I was running into a “well-kown Acme Challenge” problem such as the one addressed here: Certbot Not Creating Well-known Acme-challenges File

When certbot was creating the certificate, I chose option 2 when prompted - with the choice to REDIRECT http traffic to https

After running this command successfully - the certbot created the certificate - and upon visiting the following two test links: SSL-labs: excessive.energy & SSL-labs: www.excessive.energy it appears that things are in proper shape, however there is something very wrong with my web-server configuration, because I cannot view the content of the pages that I visit under HTTPS mode.

I assume that this most certainly has something to do with my apache configuration files. - and upon further notice, I have confirmed that there are no excessive.energy-le-ssl.conf files in either of my /etc/apache2/sites-available or /etc/apache2/sites-enabled directories.

I hope that someone can help me get to the bottom of this, because I find the whole thing to be rather mystifying and difficult to figure out. I look forward to whatever help or troubleshooting and head-scratching that any of you folks might be able to provide me with. I thank you in advance for your assistance!

Appreciatively,

Jake

Hi @Xsf_Nrg_4fr

your certificate is correct:

CN=excessive.energy
	04.03.2019
	02.06.2019
expires in 90 days	excessive.energy, www.excessive.energy - 2 entries

both connections are secure, so Ssllabs is happy. And you have a http status 404, so no content is visible.

But I don't see that redirect.

Instead:

Two http status 200 (http), two 404 - not found (https).

If you don't have an individual file, share your main config file. Perhaps there is a second file with SSL-definitions.

Looks like there is a missing DocumentRoot - directive in your SSL-config file.

Where is the configuration coming from, then?

Can you show “sudo apachectl -t -D DUMP_VHOSTS”?

What virtual hosts have that ServerAlias, ServerName or certificate?

Thank you both for your willingness and ability to help me with this.

The results of the following command are as such:

root@my-LAMP-machine:~# sudo apachectl -t -D DUMP_VHOSTS > vhosts.txt

VirtualHost configuration:
*:443…is a NameVirtualHost
… default server capecod.vacations (/etc/apache2/sites-enabled/capecod.vacations-le-ssl.conf:2)
… port 443 namevhost capecod.vacations (/etc/apache2/sites-enabled/capecod.vacations-le-ssl.conf:2)
… alias www.capecod.vacations
… port 443 namevhost info-tech.guru (/etc/apache2/sites-enabled/info-tech.guru-le-ssl.conf:2)
… alias www.info-tech.guru
… port 443 namevhost jake-onami-agnew.com (/etc/apache2/sites-enabled/jake-onami-agnew.com-le-ssl.conf:2)
… alias www.jake-onami-agnew.com
… port 443 namevhost excessive.energy (/etc/apache2/sites-enabled/phpbb-le-ssl.conf:2)
… alias www.excessive.energy
… port 443 namevhost w3blishing.com (/etc/apache2/sites-enabled/w3blishing.com-le-ssl.conf:2)
… alias www.w3blishing.com
… port 443 namevhost xsf-nrg-4.fr (/etc/apache2/sites-enabled/xsf-nrg-4.fr-le-ssl.conf:2)
… alias www.xsf-nrg-4.fr
*:80… is a NameVirtualHost
… default server capecod.vacations (/etc/apache2/sites-enabled/capecod.vacations.conf:1)
… port 80 namevhost capecod.vacations (/etc/apache2/sites-enabled/capecod.vacations.conf:1)
… alias www.capecod.vacations
… port 80 namevhost excessive.energy (/etc/apache2/sites-enabled/excessive.energy.conf:1)
… alias www.excessive.energy
… port 80 namevhost info-tech.guru (/etc/apache2/sites-enabled/info-tech.guru.conf:1)
… alias www.info-tech.guru
… port 80 namevhost jake-onami-agnew.com (/etc/apache2/sites-enabled/jake-onami-agnew.com.conf:1)
… alias www.jake-onami-agnew.com
… port 80 namevhost excessive.energy (/etc/apache2/sites-enabled/phpbb.conf:1)
… alias www.excessive.energy
… port 80 namevhost w3blishing.com (/etc/apache2/sites-enabled/w3blishing.com.conf:1)
… alias www.w3blishing.com
… port 80 namevhost xsf-nrg-4.fr (/etc/apache2/sites-enabled/xsf-nrg-4.fr.conf:1)
… alias www.xsf-nrg-4.fr

I will grab the relevant conf file as well, in just a moment.

So there were two port 80 virtual hosts, and Certbot based the HTTPS virtual host on the phpbb one.

For what it is worth, here is my apache2.conf file as well on Pastebin.

In this case, you could remove the le-ssl file that Certbot created, then remove the incorrect port 80 virtual host, and then repeat the Certbot process. Then Certbot should no longer be able to guess incorrectly between the two conflicting configurations.

Just to make sure I understand correctly schoen - is this what you propose that I do? >

delete /etc/apache2/sites-enabled/phpbb-le-ssl.conf - as well as /etc/apache2/sites-enabled/phpbb.conf…

and then run the certbot again?

Assuming that there’s nothing in those files you need to save, yes.

Yes, the question is whether these files are meant to exist or not. Apache only allows one virtual host to be effective per name and port pair, so since you have two, one of them is currently unused and probably shouldn't exist in its current form. If you can confirm which one that is and then remove it (or maybe back it up elsewhere, but not in /etc/apache2), Certbot should then be able to configure your HTTPS site in a way that better parallels the configuration of your HTTP site.

Now it works.

Both https versions are correct.

That worked like a charm!

I had installed an instance of phpBB on the site a while back, and I guess that I had enabled SSL when I created the installation or something to that effect.

I just checked thouigh, and the forum seems to work as well as there being HTTPS traffic enabled site-wide.

Thanks again to all parties involved in helping me to figure this out - and to all of those working on the project in general as well.

Happily,

Jake

My apologies if this is a bit off of topic (because it falls outside the scope of Let’sEncrypt tech support issues. However, it IS related to this thread in general, in the sense that it seems to be linked to my apache2 settings being improperly configured):

I am having some trouble with one of the sites that is listed above, within the output from the command
sudo apachectl -t -D DUMP_VHOSTS

Specifically, this site > info-tech.guru - does not properly follow through as a link to display the content of the the /var/www/info-tech.guru/public_html directory, which occurs only when I preface the URL with the www. prefix.

Plain traffic that is without the prefix, works just fine.

In an attempt to troubleshoot this issue further, I have diligently replicated the following files:

/etc/sites-enabled/jake-onami-agnew.com.conf
/etc/sites-enabled/jake-onami-agnew.com-le-ssl.conf

(while making sure to replace the relevant content with info-tech.guru stuff)… into their corresponding .conf files relating the site in question - and restarted the apache2 via:

sudo service apache2 reload && sudo service apache2 restart

… but still, no love! W_hiskey T_ango F_oxtrot

Once again, I am sorry - if this is the wrong place to be making this inquiry - but you all seem like very knowledgeable people who want to help the world, and I didn’t feel it necessary to open up a seperate thread on StackExchange or something of that sort, when there is already a conversation that is well underway here.

On the occasion that this extracurricular inquiry is too much of a burden, then perhaps someone might just as well be able to point me in the proper direction to submit such a question as this

Gratefully,

Jake

Looks a little bit chaotic:

Do you really want a redirect to /public_html/ ?

PS: It's nearly impossible to check redirects with a browser. A browser caches too much. That was one of the main ideas to create that tool.

Heheh... the story of my life i suppose :-P:

I would gladly get it better sorted out, if I only had a more solid understanding of it all.

I have my web content hosted in that folder... so perhaps the problem is that the redirect is pointing recursively from /public_html to /public_html/public_html ???

Normally the redirect refers to the view from the outside world, which typically doesn’t contain the directory name at all (unless you expect, for example, people visiting your web site to type public_html as part of the URL).

This is certainly baffling to me, but I managed to fix the problem!

Nope... that is most certainly not my intention - on my other sites, the directory structure is the same, but there is no need to specify the website.name/public_html directory when visiting the site.

Anyhow, I finally got it to work by virtue of fussing with, editing, and re-editing the .conf files as well as creating an .htaccess file for the site. I wish that I had a better understanding of exactly what went wrong - and precisely what it is that I did which fixed it.

One of my greatest frustrations in the world of tech, is when you fix something - but you don't fully understand what was broken about it in the first place. From a pragmatic perspective however - it works now - and that makes me happy!

Thanks again to everyone involved in this thread for assisting me with my website troubleshooting.

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