(snap) Everything seems to install, but 443 doesn't work

Help
1

I ran these commands:
sudo snap install --classic certbot sudo systemctl restart snapd.seeded.service
$ sudo /var/lib/snapd/snap/bin/certbot --apache

It produced this output:
IMPORTANT NOTES:

  • Unable to install the certificate (this line grayed out a little)
  • Congratulations! Your certificate and chain have been saved at:
    /etc/letsencrypt/live/ukdirectsale.co.uk/fullchain.pem
    Your key file has been saved at:
    /etc/letsencrypt/live/ukdirectsale.co.uk/privkey.pem
    Your cert will expire on 2020-12-28. To obtain a new or tweaked
    version of this certificate in the future, simply run certbot again
    with the "certonly" option. To non-interactively renew all of
    your certificates, run "certbot renew"
  • Your account credentials have been saved in your Certbot
    configuration directory at /etc/letsencrypt. You should make a
    secure backup of this folder now. This configuration directory will
    also contain certificates and private keys obtained by Certbot so
    making regular backups of this folder is ideal.

My web server is (include version):
Apache/2.4.6 (CentOS)

The operating system my web server runs on is (include version):
CentOS Linux 7

Certbot version:
certbot 1.8.0

Okay, so the Apache webserver still works for http (i.e. port 80), but despite seemingly having installed everything okay, it doesn't work at all for https (443). i.e. it simply times out.

This is the first time I've tried to use https on this machine, and I can't see what else I should be doing. I've opened port 443 on the firewall, and checked to see that Apache is listening on 443, which it is:
$ sudo netstat -tulpn | grep :443
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 20783/httpd

and ...

sudo lsof -i -P -n | grep LISTEN
...
httpd 20783 root 3u IPv4 1805264985 0t0 TCP *:80 (LISTEN)
httpd 20783 root 4u IPv4 1805264999 0t0 TCP *:443 (LISTEN)
httpd 20785 apache 3u IPv4 1805264985 0t0 TCP *:80 (LISTEN)
httpd 20785 apache 4u IPv4 1805264999 0t0 TCP *:443 (LISTEN)
httpd 20910 apache 3u IPv4 1805264985 0t0 TCP *:80 (LISTEN)
httpd 20910 apache 4u IPv4 1805264999 0t0 TCP *:443 (LISTEN)
httpd 20918 apache 3u IPv4 1805264985 0t0 TCP *:80 (LISTEN)
httpd 20918 apache 4u IPv4 1805264999 0t0 TCP *:443 (LISTEN)
httpd 21117 apache 3u IPv4 1805264985 0t0 TCP *:80 (LISTEN)
httpd 21117 apache 4u IPv4 1805264999 0t0 TCP *:443 (LISTEN)
httpd 21174 apache 3u IPv4 1805264985 0t0 TCP *:80 (LISTEN)
httpd 21174 apache 4u IPv4 1805264999 0t0 TCP *:443 (LISTEN)
httpd 21202 apache 3u IPv4 1805264985 0t0 TCP *:80 (LISTEN)
httpd 21202 apache 4u IPv4 1805264999 0t0 TCP *:443 (LISTEN)
...

I do note that no changes appear to have been made in httpd.conf (date stamp is still a couple of years old), and my vhosts file in /conf.modules.d/ remains untouched also. I figured with --classic certbot I would have noted at least a change in one of the files?

Anyway, would be extremely grateful if somebody can assist in helping me to get it working properly. Many thanks in advance!

Cheddar

2

Given the lack of information, I can only guess...
I guess that your domain points to an IP that has not had any previous port 443 access [this is your first secured domain- at this IP/server].
You've managed to enable TLS and have convinced Apache to serve your content via port 443.
Wonderful...
But if the firewall isn't allowing any inbound port 443 connections to reach your Apache server, no one will ever reach your site via that port.
Again, merely a guess.
If my guess is correct, then you have a solution.
If my guess is incorrect, then you may need to provide additional information or wait for a better guesser to come along.

1 Like
3

Additional/helpful information would be:

  • the domain name
  • output of: sudo apachectl -S
  • output of: certbot certificates
1 Like
4

As I already said, "This is the first time I've tried to use https on this machine ..... I've opened port 443 on the firewall,"

"may need to provide additional information ??? Then a suggestion in what information is needed would be helpful.

5

I had already crossed out the line and added a second post with some suggestions.

Your affirmation of "I've opened port 443" has not been shown as confirmed by anyone else, so that waits to be seen/proven.
Maybe I read all to quickly, but it seems that you only showed the port listening not actually being allowed through any firewalls.

1 Like
6

Another potentially relevant issue (GUESS #2):
Perhaps your FQDN resolves to an IPv6 address (no way for me to know).
And your bindings are only on IPv4.

1 Like
7

Ah, okay. Actually I had edited the original post to include the domain name but then had to redo the post when I had some connection issues.

Okay, so: the domain name: ukdirectsale.co.uk

$ sudo apachectl -S
[Tue Sep 29 15:01:18.009058 2020] [so:warn] [pid 26138] AH01574: module unixd_module is already loaded, skipping
[Tue Sep 29 15:01:18.026337 2020] [so:warn] [pid 26138] AH01574: module cgi_module is already loaded, skipping
[Tue Sep 29 15:01:18.026406 2020] [so:warn] [pid 26138] AH01574: module fcgid_module is already loaded, skipping
AH00548: NameVirtualHost has no effect and will be removed in the next release /etc/httpd/conf/httpd.conf:371
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.10.1.2. Set the 'ServerName' directive globally to suppress this message
VirtualHost configuration:
*:80 is a NameVirtualHost
default server www.dbserver.pc (/etc/httpd/conf.modules.d/dgb.vhosts.conf:14)
port 80 namevhost www.dbserver.pc (/etc/httpd/conf.modules.d/dgb.vhosts.conf:14)
alias dgbserver
port 80 namevhost www.ukdirectsale.co.uk (/etc/httpd/conf.modules.d/dgb.vhosts.conf:46)
alias ukdirectsale.co.uk
port 80 namevhost images.ukdirectsale.co.uk (/etc/httpd/conf.modules.d/dgb.vhosts.conf:95)
*:443 172.10.1.2 (/etc/httpd/conf.d/ssl.conf:56)
ServerRoot: "/etc/httpd"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/etc/httpd/logs/error_log"
Mutex authdigest-opaque: using_defaults
Mutex proxy-balancer-shm: using_defaults
Mutex rewrite-map: using_defaults
Mutex authdigest-client: using_defaults
Mutex fcgid-proctbl: using_defaults
Mutex ssl-stapling: using_defaults
Mutex proxy: using_defaults
Mutex authn-socache: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/run/httpd/" mechanism=default
Mutex mpm-accept: using_defaults
Mutex fcgid-pipe: using_defaults
PidFile: "/run/httpd/httpd.pid"
Define: _RH_HAS_HTTPPROTOCOLOPTIONS
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="apache" id=48
Group: name="apache" id=48

$ sudo /var/lib/snapd/snap/bin/certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Found the following certs:
Certificate Name: ukdirectsale.co.uk
Serial Number: 4a2d5cf8e7248fa25b405d14c2dbdeeae5d
Domains: ukdirectsale.co.uk images.ukdirectsale.co.uk www.ukdirectsale.co.uk
Expiry Date: 2020-12-28 16:10:57+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/ukdirectsale.co.uk/fullchain.pem
Private Key Path: /etc/letsencrypt/live/ukdirectsale.co.uk/privkey.pem

1 Like
8

Well. GUESS #2 is incorrect:

Name:    ukdirectsale.co.uk
Address:  50.195.38.3
Aliases:  www.ukdirectsale.co.uk

GUESS #1 is still in play.
I can't connect to your IP via port 443 either.

apachectl -S shows some weirdness.
Can you completely stop apache and check to ensure it is no longer running and then start it again?

1 Like
9

I had already stopped and restarted Apache, but I can do it again. As for the firewall, then I'm not quite sure what else to do other than simply allow 443 in the same manner as I already have for 80.

Yeah, okay ... restarted Apache.

1 Like
10

apachectl -S confirms this.
So you have obtained a cert but it wasn't automatically installed.
...back to the weirdness...

1 Like
11

Please show output of:
sudo apachectl configtest

12

$ sudo apachectl configtest
[Tue Sep 29 15:14:41.621657 2020] [so:warn] [pid 26991] AH01574: module unixd_module is already loaded, skipping
[Tue Sep 29 15:14:41.638732 2020] [so:warn] [pid 26991] AH01574: module cgi_module is already loaded, skipping
[Tue Sep 29 15:14:41.638807 2020] [so:warn] [pid 26991] AH01574: module fcgid_module is already loaded, skipping
AH00548: NameVirtualHost has no effect and will be removed in the next release /etc/httpd/conf/httpd.conf:371
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.10.1.2. Set the 'ServerName' directive globally to suppress this message
Syntax OK

13

There seems to be some repeated includes or such.

You may need to "walk" through your config.
Looking for anything out-of-place or unnecessary includes.

14

Those messages don't appear to be deal-breakers though; they're simply acknowledging that the modules are defined in more than one place (for whatever reason). I don't really see they would have any bearing on the issue at hand.

15

Then you may be missing the bigger picture.
The problem of those mods being loaded more than once is not the problem we are looking for - true.
But they are an indication of something out of place and possibly much more is being loaded along with those lines - like an included file that includes a file that includes some mods. [but if several files include the file that includes the files... or the include is being done within a block where that should not happen then there may be other consequences that go untold]
If you didn't know, now you will know:
Apache is notorious for running at any/all costs.
Even when the configtest passes, the config may still be problematic for certbots [and humans too].

16

And you don't really see the problem either so...
How can you be truly certain the problem isn't where you think it is not?

17

Well, anything that gets it working will be welcome, but unrelated modules being skipped (they're not loaded more than once) on start-up just don't strike me as being a primary suspect.

Anyway, just going through stuff to find the duplicate definitions.

$ sudo grep unixd_module -rI /etc/httpd/*|grep -v "error_log"
/etc/httpd/conf/httpd.conf:LoadModule unixd_module modules/mod_unixd.so
/etc/httpd/conf.modules.d/00-base.conf:LoadModule unixd_module modules/mod_unixd.so

$ sudo grep cgi_module -rI /etc/httpd/*|grep -v "error_log"
/etc/httpd/conf/httpd.conf:LoadModule cgi_module modules/mod_cgi.so
/etc/httpd/conf.modules.d/00-proxy.conf:LoadModule proxy_fcgi_module modules/mod_proxy_fcgi.so
/etc/httpd/conf.modules.d/00-proxy.conf:LoadModule proxy_scgi_module modules/mod_proxy_scgi.so
/etc/httpd/conf.modules.d/01-cgi.conf:   LoadModule cgi_module modules/mod_cgi.so

$ sudo grep fcgid_module -rI /etc/httpd/*|grep -v "error_log"
/etc/httpd/conf/httpd.conf:LoadModule fcgid_module modules/mod_fcgid.so
/etc/httpd/conf.modules.d/10-fcgid.conf:LoadModule fcgid_module modules/mod_fcgid.so
18

I take it that all seems normal and expected to your programming style...

So we can beat this until it does what we want and how we want it - no telling how long that will take.
OR
We can manually create the server block(s) it failed to create - this should be straight-forward.
TLS enabled versions of:

19

I would take the server blocks containing these lines - one at a time:

20

All three would use these same two file, so that is an easy copy/paste once written correctly.