Certificate Showing as localhost.localdomain?

The latest one you showed. The ssl.conf file that has this:

This default VHost does not have an explicit name and ends up overlapped with your other -le-ssl conf file (per dump_vhosts)

3 Likes

*.80
Should be:
*:80

3 Likes

Does the default DocumentRoot and ServerName need uncommenting and populating with something like {ip}.my-website.com ?

I'd have thought Apache would have ignored that if there is nothing populated and routed straight through to the separate conf file and -le-ssl.conf file.

I can populate them with something, just didn't think I needed to.

Look back at post #13 and the DUMP_VHOSTS output. You will see two VirtualHosts with the same name for the same port. Apache may very well always choose the first of those. But, it is prone to failure if/as you make changes to the server config.

Does not matter what value for ServerName. Call it Michael.Default if you like :slight_smile:

Have you sorted the other config problems shown by httpd -t -D DUMP_VHOSTS ?

2 Likes

I had a play with configuring the ss.conf file to be the public IP as a DNS-able route (also configured the DNS to point correctly) which ended up like;

[root@localhost conf.d]# httpd -t -D DUMP_VHOSTS
AH00112: Warning: DocumentRoot [/var/www/public_html] does not exist
VirtualHost configuration:
*:80                   mk1.contrado.cloud (/etc/httpd/conf.d/mk1.contrado.cloud.conf:1)
*:443                  is a NameVirtualHost
         default server mk1.contrado.cloud (/etc/httpd/conf.d/mk1.contrado.cloud-le-ssl.conf:2)
         port 443 namevhost mk1.contrado.cloud (/etc/httpd/conf.d/mk1.contrado.cloud-le-ssl.conf:2)
         port 443 namevhost 62-3-66-193.mk1.contrado.cloud (/etc/httpd/conf.d/ssl.conf:56)

Which looks like that has solved the 443 and hostmame conflict.

What is interesting is that even when this conflict is in place, things seemed to work fine. But it's always best to configure things properly.

I 'think' this is correct. But it's difficult to say for sure as the guides online show the art of the possible for endless scenarios, so it's not like I can easily confirm what is correct/not correct. I'm not sure I fully understand yet how to interpret what is correct/incorrect from the DUMP_VHOSTS output, is there any guide you could recommend which helps to understand what is good/bad with this output?

If I've understood correctly, what is important is to set the main httpd.conf to have a default ServerName of whatver.com, and then when SSL/Cerbot is run, then the ss.conf ends up with the same config within ssl.conf - as long as this doesn't conflict with the separate files for something-else.conf in the conf.d folder, then this ensures things are kept separate.

The Apache docs are always good place to start. There are many poor guides on the internet, I agree. Especially for Apache. I don't have a good beginner's guide to recommend off-hand. Maybe another volunteer will.

I didn't see this value for DocumentRoot in any prior posts of your config. So, it seems you must have added it recently. If that value is used in a VirtualHost you care about you must change it to a valid folder. It's not a bad idea to fix that anyway.

I didn't quite follow that :slight_smile: But, a common technique is to have each VirtualHost in its own file. In the main httpd.conf you use Include to, well, include them in the overall config. Some systems (like Ubuntu) standardize on folders of /sites-available/ and /sites-enabled/ for this. In fact, the ubuntu website has a very nice writeup of Apache config folder structure but that will likely cause more confusion for you since it has other key differences from your Centos.

There are several ways to run Certbot. But, for the --apache plug-in having separate files works well. For a new domain you create a file with just the VirtualHost for port 80 for that domain name (say, example.com.conf). You test access to that domain. Then run Certbot with --apache which will create the -le-ssl.conf file if you pass the challenge test.

3 Likes

Does this look correct for the output of the DUMP_VHOSTS?

[root@localhost ~]# httpd -t -D DUMP_VHOSTS
VirtualHost configuration:
*:80                   helloworld.contrado.cloud (/etc/httpd/conf.d/helloworld.contrado.cloud.conf:1)
*:443                  is a NameVirtualHost
         default server helloworld.contrado.cloud (/etc/httpd/conf.d/helloworld.contrado.cloud-le-ssl.conf:2)
         port 443 namevhost helloworld.contrado.cloud (/etc/httpd/conf.d/helloworld.contrado.cloud-le-ssl.conf:2)
         port 443 namevhost 192-1-2-3.mk1.contrado.cloud (/etc/httpd/conf.d/ssl.conf:56)

If I've understood correctly, that now means there is no conflict. My last response probably didn't explain my thoughts very well, but the above is what I understood in terms of implementation and expected output.

Yes, that looks better. Is everything working well now? Or, what problems remain?

3 Likes

Great thanks for the confirmation @MikeMcQ

There was actually no behavioural change before/after the change. Things worked in both scenarios for Let's Encrypt, seems that Apache is fairly smart under the hood regardless of any conflicts.

All I did to change the output of the DUMP_VHOSTS was to edit the ServerName variable in the default httpd.conf and ssl.conf files.

Seems more of a nice to have more than anything. And ultimately nothing specifically related to Let's Encrypt.

Clearly just an issue on my end with the various combination/permutations of trials for getting this example spun up end to end which ultimately had things done in the slightly wrong order.

1 Like

"Smart" is generous :slight_smile: But, having clear, "best practice" config helps avoid unexpected problems with seemingly minor future changes.

Glad it's working well.

4 Likes

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