I'm trying to set up a simple web server for personal use, using Apache, and want to enable HTTPS access. This involves getting an SSL certificate and I'll be using LetsEncrypt (www.letsencrypt.org).
The recommended way to do this is with Certbot, but I can't get past this error:
# certbot --apache -d bree.org.uk Saving debug log to /var/log/letsencrypt/letsencrypt.log Requesting a certificate for bree.org.uk Unable to find a virtual host listening on port 80 which is currently needed for Certbot to prove to the CA that you control your domain. Please add a virtual host for port 80. Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
Note that the httpd server is online and reachable from outside my local net, i.e. this doesn't appear to be a firewall issue.
I've reported the problem upstream and followed a number of suggestions, but nothing seems to make any difference:
https://community.letsencrypt.org/t/certbot-fails-with-cant-find-virtual-hos...
Any thoughts on this would be welcome, but please review the above link before replying.
poc
Sat, 22 Apr 2023 13:11:45 +0100 Patrick O'Callaghan pocallaghan@gmail.com kirjoitti:
I'm trying to set up a simple web server for personal use, using Apache, and want to enable HTTPS access. This involves getting an SSL certificate and I'll be using LetsEncrypt (www.letsencrypt.org).
Have you thought about http://nginx.org/en/docs/http/configuring_https_servers.html
Instead of apache?
Jarmo
On Sat, 2023-04-22 at 15:55 +0300, jarmo wrote:
Sat, 22 Apr 2023 13:11:45 +0100 Patrick O'Callaghan pocallaghan@gmail.com kirjoitti:
I'm trying to set up a simple web server for personal use, using Apache, and want to enable HTTPS access. This involves getting an SSL certificate and I'll be using LetsEncrypt (www.letsencrypt.org).
Have you thought about http://nginx.org/en/docs/http/configuring_https_servers.html
Instead of apache?
No. I barely understand Apache and don't want to introduce another variable.
poc
On 04/22/2023 11:41 AM, Patrick O'Callaghan wrote:
No. I barely understand Apache and don't want to introduce another variable.
If I were writing an encryption package, I think I'd name it Navajo, after the WW II code talkers. I understand that some of the slang they used for things such as tanks and bombers that weren't in their language were quite imaginative.
Am 22.04.23 um 14:11 schrieb Patrick O'Callaghan:
I'm trying to set up a simple web server for personal use, using Apache, and want to enable HTTPS access. This involves getting an SSL certificate and I'll be using LetsEncrypt (www.letsencrypt.org).
The recommended way to do this is with Certbot, but I can't get past this error:
# certbot --apache -d bree.org.uk Saving debug log to /var/log/letsencrypt/letsencrypt.log Requesting a certificate for bree.org.uk Unable to find a virtual host listening on port 80 which is currently needed for Certbot to prove to the CA that you control your domain. Please add a virtual host for port 80. Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
Note that the httpd server is online and reachable from outside my local net, i.e. this doesn't appear to be a firewall issue.
I've reported the problem upstream and followed a number of suggestions, but nothing seems to make any difference:
https://community.letsencrypt.org/t/certbot-fails-with-cant-find-virtual-hos...
Any thoughts on this would be welcome, but please review the above link before replying.
If certbot --apache doesn't work, you could try to only fetch the certificates and manually configure httpd to actually use them afterwards. I. e. do something like
# certbot certonly --webroot -w /path/to/webroot -d $DOMAIN ...
On Sat, 2023-04-22 at 15:30 +0200, Markus Schönhaber wrote:
Am 22.04.23 um 14:11 schrieb Patrick O'Callaghan:
I'm trying to set up a simple web server for personal use, using Apache, and want to enable HTTPS access. This involves getting an SSL certificate and I'll be using LetsEncrypt (www.letsencrypt.org).
The recommended way to do this is with Certbot, but I can't get past this error:
# certbot --apache -d bree.org.uk Saving debug log to /var/log/letsencrypt/letsencrypt.log Requesting a certificate for bree.org.uk Unable to find a virtual host listening on port 80 which is currently needed for Certbot to prove to the CA that you control your domain. Please add a virtual host for port 80. Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
Note that the httpd server is online and reachable from outside my local net, i.e. this doesn't appear to be a firewall issue.
I've reported the problem upstream and followed a number of suggestions, but nothing seems to make any difference:
https://community.letsencrypt.org/t/certbot-fails-with-cant-find-virtual-hos...
Any thoughts on this would be welcome, but please review the above link before replying.
If certbot --apache doesn't work, you could try to only fetch the certificates and manually configure httpd to actually use them afterwards. I. e. do something like
# certbot certonly --webroot -w /path/to/webroot -d $DOMAIN ...
I've considered that (there are several other ACME clients on Fedora) but Certbot is the recommended one so I'm sticking with it for now.
poc
22.04.23, 19:42 +0200, Patrick O'Callaghan:
On Sat, 2023-04-22 at 15:30 +0200, Markus Schönhaber wrote:
If certbot --apache doesn't work, you could try to only fetch the certificates and manually configure httpd to actually use them afterwards. I. e. do something like
# certbot certonly --webroot -w /path/to/webroot -d $DOMAIN ...
I've considered that (there are several other ACME clients on Fedora) but Certbot is the recommended one so I'm sticking with it for now.
What are you talking about? The command I showed you above *is* a certbot invocation.
On Sat, 2023-04-22 at 23:31 +0200, Markus Schönhaber wrote:
22.04.23, 19:42 +0200, Patrick O'Callaghan:
On Sat, 2023-04-22 at 15:30 +0200, Markus Schönhaber wrote:
If certbot --apache doesn't work, you could try to only fetch the certificates and manually configure httpd to actually use them afterwards. I. e. do something like
# certbot certonly --webroot -w /path/to/webroot -d $DOMAIN ...
I've considered that (there are several other ACME clients on Fedora) but Certbot is the recommended one so I'm sticking with it for now.
What are you talking about? The command I showed you above *is* a certbot invocation.
I know it's a Certbot invocation. I'm merely saying that Certbot is not the only way to obtain certificates using the ACME protocol.
poc
22.04.23, 23:40 +0200, Patrick O'Callaghan:
On Sat, 2023-04-22 at 23:31 +0200, Markus Schönhaber wrote:
22.04.23, 19:42 +0200, Patrick O'Callaghan:
On Sat, 2023-04-22 at 15:30 +0200, Markus Schönhaber wrote:
If certbot --apache doesn't work, you could try to only fetch the certificates and manually configure httpd to actually use them afterwards. I. e. do something like
# certbot certonly --webroot -w /path/to/webroot -d $DOMAIN ...
I've considered that (there are several other ACME clients on Fedora) but Certbot is the recommended one so I'm sticking with it for now.
What are you talking about? The command I showed you above *is* a certbot invocation.
I know it's a Certbot invocation. I'm merely saying that Certbot is not the only way to obtain certificates using the ACME protocol.
Yes, and you're also saying that you don't want to use those other ACME clients but rather stick to certbot. So you dismiss my proposed way to use certbot because there are other ACME clients but you'd rather use certbot. Now, that makes sense.
On Sun, 2023-04-23 at 15:21 +0200, Markus Schönhaber wrote:
22.04.23, 23:40 +0200, Patrick O'Callaghan:
On Sat, 2023-04-22 at 23:31 +0200, Markus Schönhaber wrote:
22.04.23, 19:42 +0200, Patrick O'Callaghan:
On Sat, 2023-04-22 at 15:30 +0200, Markus Schönhaber wrote:
If certbot --apache doesn't work, you could try to only fetch the certificates and manually configure httpd to actually use them afterwards. I. e. do something like
# certbot certonly --webroot -w /path/to/webroot -d $DOMAIN ...
I've considered that (there are several other ACME clients on Fedora) but Certbot is the recommended one so I'm sticking with it for now.
What are you talking about? The command I showed you above *is* a certbot invocation.
I know it's a Certbot invocation. I'm merely saying that Certbot is not the only way to obtain certificates using the ACME protocol.
Yes, and you're also saying that you don't want to use those other ACME clients but rather stick to certbot. So you dismiss my proposed way to use certbot because there are other ACME clients but you'd rather use certbot. Now, that makes sense.
You're parsing too strictly. I'm saying I would prefer to use Certbot (as it seems to be the solution recommended by LetsEncrypt) but I'm aware of other ACME clients.
In fact I'm also looking at Apache's mod_md as an alternative.
Currently, the most likely source of the problem I'm having is not Certbot as such but something in my Apache configuration. I'm going over it again to check everything.
poc
On Sun, 2023-04-23 at 15:01 +0100, Patrick O'Callaghan wrote:
On Sun, 2023-04-23 at 15:21 +0200, Markus Schönhaber wrote:
22.04.23, 23:40 +0200, Patrick O'Callaghan:
On Sat, 2023-04-22 at 23:31 +0200, Markus Schönhaber wrote:
22.04.23, 19:42 +0200, Patrick O'Callaghan:
On Sat, 2023-04-22 at 15:30 +0200, Markus Schönhaber wrote:
If certbot --apache doesn't work, you could try to only fetch the certificates and manually configure httpd to actually use them afterwards. I. e. do something like
# certbot certonly --webroot -w /path/to/webroot -d $DOMAIN ...
I've considered that (there are several other ACME clients on Fedora) but Certbot is the recommended one so I'm sticking with it for now.
What are you talking about? The command I showed you above *is* a certbot invocation.
I know it's a Certbot invocation. I'm merely saying that Certbot is not the only way to obtain certificates using the ACME protocol.
Yes, and you're also saying that you don't want to use those other ACME clients but rather stick to certbot. So you dismiss my proposed way to use certbot because there are other ACME clients but you'd rather use certbot. Now, that makes sense.
You're parsing too strictly. I'm saying I would prefer to use Certbot (as it seems to be the solution recommended by LetsEncrypt) but I'm aware of other ACME clients.
In fact I'm also looking at Apache's mod_md as an alternative.
Currently, the most likely source of the problem I'm having is not Certbot as such but something in my Apache configuration. I'm going over it again to check everything.
BTW 'certbot certonly ..." also failed. I'm 99% sure this is a problem with my Apache installation.
poc
On Sun, 23 Apr 2023 15:10:58 +0100 Patrick O'Callaghan wrote:
BTW 'certbot certonly ..." also failed. I'm 99% sure this is a problem with my Apache installation.
Well, the apache documentation is only 11,371 pages, so it should be easy to find :-).
That's basically why I'm using dnsmasq now instead of named.
Once upon a time, Patrick O'Callaghan pocallaghan@gmail.com said:
BTW 'certbot certonly ..." also failed. I'm 99% sure this is a problem with my Apache installation.
I think others have mentioned it, but I would highly suggest using --webroot rather than --apache. You have control of the Apache config that way and can get it right (once) and be done with it, just pointing certbot to your chosen and configured directory.
The validation step does use port 80, due to pre-SNI shared hosting servers sometimes serving site A's content on port 443 for site B's URL (allowing site A to impersonate site B for ACME purposes). Especially if you aren't otherwise using port 80, you can just configure an Apache virtual host on port 80 and point it to an otherwise-unused directory, to use with --webroot.
I do most of my Let's Encrypt cert validation with DNS these days (to allow for wildcard certs and/or hosts on private networks), so that's about it for ideas from me. :)
On Sun, 2023-04-23 at 09:33 -0500, Chris Adams wrote:
Once upon a time, Patrick O'Callaghan pocallaghan@gmail.com said:
BTW 'certbot certonly ..." also failed. I'm 99% sure this is a problem with my Apache installation.
I think others have mentioned it, but I would highly suggest using --webroot rather than --apache. You have control of the Apache config that way and can get it right (once) and be done with it, just pointing certbot to your chosen and configured directory.
Certbot won't even run in interactive mode because of errors with Apache itself (see my reply to Tim).
poc
On Sun, 2023-04-23 at 15:10 +0100, Patrick O'Callaghan wrote:
I'm 99% sure this is a problem with my Apache installation.
On my internal test server, I use virtual hosts for the various websites I maintain (I have local test versions that are exported to the external servers that host the public versions). And I leave the default website (the one that you'll get if you browse to the numerical IP address) alone, so you just see the default Apache test page.
If I look at the HTTP headers (e.g. wget -S http://example.com/) I see very little difference between one internal or external site versus another (basically just the size, etag hash, date, of the particular file being served). There's nothing that obviously says which particular service is being accessed (Certbots thing about virtual host config demands seems even more oddball). Apache ServerName variables seem to be only used when Apache generates some HTML content that specifically includes them.
If you browse to http://bree.org.uk/ and https://bree.org.uk/ do you get the same results?
If I try web browsing your site, I get the same "books" page to either address. There is a HTTPS connection, but it complains it's not secure. There's no obvious indication about who issued the certificate.
Likewise, do you get the same results with browsing for a specific serveable file?
Likewise internally and externally? (Viewing one of your pages through a HTML validator is one way to see what the outside world sees, if you don't have some external proxy you can use, or a VPN.)
I'm assuming that part of the problem is *external* access to port 80, does your ISP put something in the way of the port?
Do you have some *other* certificate already there that's confusing things?
My own (externally hosted) website has a problem that continually irritates me: They cache the content and serve from the cache to the outside world. Sometimes it takes an absolute age for changed content to flow through. No amount of reloading, or using a different browser, or deleting and replacing files, shows the new content. Even though I had set HTTP header parameters for short caching lifespans.
I detest non-Apache servers that falsely claim to be Apache drop-in replacements (e.g. LiteSpeed). About all they care about is supporting template websites (e.g. WordPress).
On Mon, 2023-04-24 at 02:36 +0930, Tim via users wrote:
If you browse to http://bree.org.uk/%C2%A0and%C2%A0https://bree.org.uk/ do you get the same results?
Internally, yes.
If I try web browsing your site, I get the same "books" page to either address. There is a HTTPS connection, but it complains it's not secure. There's no obvious indication about who issued the certificate.
There is no certificate.
Likewise, do you get the same results with browsing for a specific serveable file?
Yes
Likewise internally and externally? (Viewing one of your pages through a HTML validator is one way to see what the outside world sees, if you don't have some external proxy you can use, or a VPN.)
Internally and externally show the same content.
I'm assuming that part of the problem is *external* access to port 80, does your ISP put something in the way of the port?
Not that I know of. Browsing to port 80 works as it should.
Do you have some *other* certificate already there that's confusing things?
I currently have no certs.
The reason I suspect an Apache problem is as follows: when I configured the VirtualHost, it was via an included file:
# pwd /etc/httpd/conf.d [root@Bree conf.d]# cat bree.conf <VirtualHost *:80> ServerName bree.org.uk ServerAdmin pocallaghan@gmail.com DocumentRoot /var/www/bree.org.uk/html ErrorLog /var/www/bree.org.uk/error.log CustomLog /var/www/bree.org.uk/log/access.log combined </VirtualHost> # tail -2 ../conf/httpd.conf # Load config files in the "/etc/httpd/conf.d" directory, if any. IncludeOptional conf.d/*.conf
Now when I start Apache I get: # apachectl restart Job for httpd.service failed because the control process exited with error code. See "systemctl status httpd.service" and "journalctl -xeu httpd.service" for details.
The only warning in the journal is: Failed to start httpd.service - The Apache HTTP Server.
IOW Apache simply fails to start when I try to use the VirtualHost directive, but provides no useful information. Furthermore: # httpd -t -D DUMP_HOSTS Syntax OK #
So Apache itself says there is no syntax error in the file(s).
So why do I say that I can browse to port 80? Because when I *don't* include that bree.conf file, everything starts up and runs. Therefore the problem logically is in that file, but despite careful scanning of the Apache docs I can't see what it is. Note that the various files referenced in bree.conf all exist and are world-readable:
# ls -l /var/www/bree.org.uk/html total 4 -rwxr-xr-x. 1 apache apache 159 Apr 16 22:24 index.html [root@Bree conf.d]# ls -l /var/www/bree.org.uk/error.log -rw-r--r--. 1 root root 0 Apr 21 22:28 /var/www/bree.org.uk/error.log [root@Bree conf.d]# ls -l /var/www/bree.org.uk/log/access.log ls: cannot access '/var/www/bree.org.uk/log/access.log': No such file or directory [root@Bree conf.d]# ls -l /var/www/bree.org.uk/log total 0
poc
On 4/23/23 10:45, Patrick O'Callaghan wrote:
On Mon, 2023-04-24 at 02:36 +0930, Tim via users wrote:
If you browse to http://bree.org.uk/%C2%A0and%C2%A0https://bree.org.uk/ do you get the same results?
Internally, yes.
If I try web browsing your site, I get the same "books" page to either address. There is a HTTPS connection, but it complains it's not secure. There's no obvious indication about who issued the certificate.
There is no certificate.
Likewise, do you get the same results with browsing for a specific serveable file?
Yes
Likewise internally and externally? (Viewing one of your pages through a HTML validator is one way to see what the outside world sees, if you don't have some external proxy you can use, or a VPN.)
Internally and externally show the same content.
I'm assuming that part of the problem is *external* access to port 80, does your ISP put something in the way of the port?
Not that I know of. Browsing to port 80 works as it should.
Do you have some *other* certificate already there that's confusing things?
I currently have no certs.
The reason I suspect an Apache problem is as follows: when I configured the VirtualHost, it was via an included file:
# pwd /etc/httpd/conf.d [root@Bree conf.d]# cat bree.conf <VirtualHost *:80> ServerName bree.org.uk ServerAdmin pocallaghan@gmail.com DocumentRoot /var/www/bree.org.uk/html ErrorLog /var/www/bree.org.uk/error.log CustomLog /var/www/bree.org.uk/log/access.log combined
</VirtualHost> # tail -2 ../conf/httpd.conf # Load config files in the "/etc/httpd/conf.d" directory, if any. IncludeOptional conf.d/*.conf
Now when I start Apache I get: # apachectl restart Job for httpd.service failed because the control process exited with error code. See "systemctl status httpd.service" and "journalctl -xeu httpd.service" for details.
The only warning in the journal is: Failed to start httpd.service - The Apache HTTP Server.
IOW Apache simply fails to start when I try to use the VirtualHost directive, but provides no useful information. Furthermore: # httpd -t -D DUMP_HOSTS Syntax OK #
So Apache itself says there is no syntax error in the file(s).
So why do I say that I can browse to port 80? Because when I *don't* include that bree.conf file, everything starts up and runs. Therefore the problem logically is in that file, but despite careful scanning of the Apache docs I can't see what it is. Note that the various files referenced in bree.conf all exist and are world-readable:
# ls -l /var/www/bree.org.uk/html total 4 -rwxr-xr-x. 1 apache apache 159 Apr 16 22:24 index.html [root@Bree conf.d]# ls -l /var/www/bree.org.uk/error.log -rw-r--r--. 1 root root 0 Apr 21 22:28 /var/www/bree.org.uk/error.log [root@Bree conf.d]# ls -l /var/www/bree.org.uk/log/access.log ls: cannot access '/var/www/bree.org.uk/log/access.log': No such file or directory [root@Bree conf.d]# ls -l /var/www/bree.org.uk/log total 0
Is there anything useful in the server's error.log? Startup errors should be there.
Hi.
On Sun, 23 Apr 2023 18:45:10 +0100 Patrick O'Callaghan wrote:
The reason I suspect an Apache problem is as follows: when I configured the VirtualHost, it was via an included file:
Now when I start Apache I get: # apachectl restart Job for httpd.service failed because the control process exited with error code. See "systemctl status httpd.service" and "journalctl -xeu httpd.service" for details.
The only warning in the journal is: Failed to start httpd.service - The Apache HTTP Server.
You may find more details in the main error_log file of Apache:
/var/log/httpd/error_log
On 4/23/23, Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Mon, 2023-04-24 at 02:36 +0930, Tim via users wrote:
If you browse to http://bree.org.uk/ and https://bree.org.uk/ do you get the same results?
Internally, yes.
If you want a *publicly* trusted certificate the authentication token from Let's Encrypt or other certificate provider must be made *publicly* accessible somehow.
For http-01 authentication as used by certbot's apache auto-configuration and webroot methods your web server must be publicly accessible on port 80.
For tls-alpn-01 authentication as used by Apache's mod_md module your web server must be publicly accessible on port 443.
If this is not acceptable consider using dns-01 authentication method mentioned upthread if your DNS provider has an API or you run your own, or even a private CA.
On 4/23/23, T.C. Hollingsworth tchollingsworth@gmail.com wrote:
On 4/23/23, Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Mon, 2023-04-24 at 02:36 +0930, Tim via users wrote:
If you browse to http://bree.org.uk/ and https://bree.org.uk/ do you get the same results?
Internally, yes.
If you want a *publicly* trusted certificate
Sorry I see Tim was able to browse your website earlier but I wasn't so I thought this might have meant it was intended to be this way but you are probably just working on things right now :-D
Webroot authentication is pretty simple, what trips most people up is it puts it in a dot directory /.well-known/acme-challenge/ and a lot of open source packages include Apache rules that block dotfiles with errors to hide these files so see if you have any rules like that or specifically whitelist that path.
On Sun, 2023-04-23 at 12:21 -0700, T.C. Hollingsworth wrote:
Webroot authentication is pretty simple, what trips most people up is it puts it in a dot directory /.well-known/acme-challenge/ and a lot of open source packages include Apache rules that block dotfiles with errors to hide these files so see if you have any rules like that or specifically whitelist that path.
Access to files named like them is still allowed, they're just not shown in automatic directory listings in the browser.
Specific files like .htaccess and .htpasswd ought to be blocked.
On Mon, 2023-04-24 at 05:06 +0930, Tim via users wrote:
On Sun, 2023-04-23 at 12:21 -0700, T.C. Hollingsworth wrote:
Webroot authentication is pretty simple, what trips most people up is it puts it in a dot directory /.well-known/acme-challenge/ and a lot of open source packages include Apache rules that block dotfiles with errors to hide these files so see if you have any rules like that or specifically whitelist that path.
Access to files named like them is still allowed, they're just not shown in automatic directory listings in the browser.
Specific files like .htaccess and .htpasswd ought to be blocked.
I had a look at /var/log/httpd/error_log and found this:
httpd: could not open error log file /var/www/bree.org.uk/error.log
I rechecked and that file definitely exists and is writable by root (which httpd runs as). However a suspicion arose and I decided to turn off SElinux and reload.
And it worked. Not only that, but certbot worked as well:
# httpd -t -D DUMP_VHOSTS VirtualHost configuration: *:80 bree.org.uk (/etc/httpd/conf.d/bree.conf:1) *:443 is a NameVirtualHost default server bree.org.uk (/etc/httpd/conf.d/bree-le-ssl.conf:2) port 443 namevhost bree.org.uk (/etc/httpd/conf.d/bree-le-ssl.conf:2) port 443 namevhost bree.org.uk (/etc/httpd/conf.d/ssl.conf:56)
I'm well aware that you had mentioned SElinux earlier, and I had definitely done tests having turned it off, but clearly I missed something.
I may have caused the problem by changing ownership of some files to apache:apache without considering their SElinux context. For the time being I'm keeping setenforce=0 until I can figure this out (suggestions are of course welcome).
Effusive thanks to the multiple people who chipped in with ideas.
poc
On 4/23/23 14:50, Patrick O'Callaghan wrote:
I had a look at /var/log/httpd/error_log and found this:
httpd: could not open error log file /var/www/bree.org.uk/error.logI rechecked and that file definitely exists and is writable by root (which httpd runs as). However a suspicion arose and I decided to turn off SElinux and reload.
As someone else mentioned, why are you writing logs to the web server data directory? There's a directory (/var/log/httpd) that's already intended for that. The file context is most likely going to be wrong, which is why selinux is (rightly) blocking it.
On Sun, 2023-04-23 at 14:56 -0700, Samuel Sieb wrote:
On 4/23/23 14:50, Patrick O'Callaghan wrote:
I had a look at /var/log/httpd/error_log and found this:
httpd: could not open error log file /var/www/bree.org.uk/error.log
I rechecked and that file definitely exists and is writable by root (which httpd runs as). However a suspicion arose and I decided to turn off SElinux and reload.
As someone else mentioned, why are you writing logs to the web server data directory? There's a directory (/var/log/httpd) that's already intended for that. The file context is most likely going to be wrong, which is why selinux is (rightly) blocking it.
Why? Because being unfamiliar with Apache (and Certbot) I was foolishly following an online step-by-step guide:
https://www.linuxshelltips.com/install-apache-fedora-linux/
I've since seen the error of my ways and it seems to be working now.
poc
Samuel Sieb:
As someone else mentioned, why are you writing logs to the web server data directory? There's a directory (/var/log/httpd) that's already intended for that. The file context is most likely going to be wrong, which is why selinux is (rightly) blocking it.
Patrick O'Callaghan:
Why? Because being unfamiliar with Apache (and Certbot) I was foolishly following an online step-by-step guide:
https://www.linuxshelltips.com/install-apache-fedora-linux/
I've since seen the error of my ways and it seems to be working now.
I'm a bit surprised at that site's recommendations. It's quite different from info I've read before, and how the default Apache install on Fedora is set up. My guess is that they've followed some other example, and then just put "Fedora" into the text in a few key places. It's surprising it doesn't also say, first switch off SELinux.
The SELinux contexts are applied to files created in certain expected places. I don't know whether SELinux has pre-existing rules for logs in more than one place. We generally expect logs somewhere under /var/log, though. Apache may require specific /httpd log/ contexts to be able to write to them.
I've seen other wierd examples, where they've put the logs inside /etc/httpd/ or put symlinks to their real location inside there.
Generally, the main Apache config is in /etc/httpd/conf/httpd.conf, and it will "include" any other .conf configuration files from /etc/httpd/conf.d/ for customisation (where you could put your virtual site configs, as well as any other add-ons).
That site's whole bit about sites-available and sites-enabled, with symlinking, is a rat's nest of directories that I've never encountered before. We already have an /etc/httpd/conf.d/ that can hold all extra config files. And you can easily create an extra conf.disabled directory, or rename them to not end in .conf, if you want to shift a config file and see how things work without it.
Looking at other examples, the default site is inside /var/www/html, and then they've suggested virtual hosted sites to go inside it as sub- directories, meaning the default site can lead incorrectly into the various virtual sites. That could lead to all sorts of bypassing of access controls.
(The *default* site being what's served if you don't request a site by a recognised hostname. But if you only have ONE site, it could be the default one.)
Other examples suggest schemes like this:
/var/www/html/ (the default site) /var/www/now-to-eat-pizza/ (one of your virtual sites) /var/www/exercising-your-pet-rock/ (another of your virtual sites)
The whole /var/www/ is a bit odd, too. It's probably no more variable content than your own personal files. Other instructions advise websites should be served from /srv/
There's all sorts of very different example suggestions, and some of them are bad advice.
On Mon, 2023-04-24 at 22:21 +0930, Tim via users wrote:
Samuel Sieb:
As someone else mentioned, why are you writing logs to the web server data directory? There's a directory (/var/log/httpd) that's already intended for that. The file context is most likely going to be wrong, which is why selinux is (rightly) blocking it.
Patrick O'Callaghan:
Why? Because being unfamiliar with Apache (and Certbot) I was foolishly following an online step-by-step guide:
https://www.linuxshelltips.com/install-apache-fedora-linux/
I've since seen the error of my ways and it seems to be working now.
I'm a bit surprised at that site's recommendations. It's quite different from info I've read before, and how the default Apache install on Fedora is set up. My guess is that they've followed some other example, and then just put "Fedora" into the text in a few key places. It's surprising it doesn't also say, first switch off SELinux.
Yes, it's that most dangerous thing: *nearly* right.
[...]
The *default* site being what's served if you don't request a site by a recognised hostname. But if you only have ONE site, it could be the default one.)
That's probably related to Certbot wanting a virtual host.
Other examples suggest schemes like this:
/var/www/html/ (the default site) /var/www/now-to-eat-pizza/ (one of your virtual sites) /var/www/exercising-your-pet-rock/ (another of your virtual sites)
The whole /var/www/ is a bit odd, too. It's probably no more variable content than your own personal files. Other instructions advise websites should be served from /srv/
There's all sorts of very different example suggestions, and some of them are bad advice.
I see that.
poc
On 4/24/23 05:51, Tim via users wrote:
That site's whole bit about sites-available and sites-enabled, with symlinking, is a rat's nest of directories that I've never encountered before. We already have an /etc/httpd/conf.d/ that can hold all extra config files. And you can easily create an extra conf.disabled directory, or rename them to not end in .conf, if you want to shift a config file and see how things work without it.
That's the debian style apache config. You configure sites in one directory and then they are activated by symlinking into the other one.
On Mon, 2023-04-24 at 10:44 -0700, Samuel Sieb wrote:
On 4/24/23 05:51, Tim via users wrote:
That site's whole bit about sites-available and sites-enabled, with symlinking, is a rat's nest of directories that I've never encountered before. We already have an /etc/httpd/conf.d/ that can hold all extra config files. And you can easily create an extra conf.disabled directory, or rename them to not end in .conf, if you want to shift a config file and see how things work without it.
That's the debian style apache config. You configure sites in one directory and then they are activated by symlinking into the other one.
I assume the author took a Debian guide and made some adjustments for Fedora without thinking it through.
poc
On Mon, Apr 24, 2023 at 5:14 AM Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Sun, 2023-04-23 at 14:56 -0700, Samuel Sieb wrote:
On 4/23/23 14:50, Patrick O'Callaghan wrote:
I had a look at /var/log/httpd/error_log and found this:
httpd: could not open error log file/var/www/bree.org.uk/error.log
I rechecked and that file definitely exists and is writable by root (which httpd runs as). However a suspicion arose and I decided to turn off SElinux and reload.
As someone else mentioned, why are you writing logs to the web server data directory? There's a directory (/var/log/httpd) that's already intended for that. The file context is most likely going to be wrong, which is why selinux is (rightly) blocking it.
Why? Because being unfamiliar with Apache (and Certbot) I was foolishly following an online step-by-step guide:
https://www.linuxshelltips.com/install-apache-fedora-linux/
I've since seen the error of my ways and it seems to be working now.
Yeah, first try Fedora docs at docs.fedoraproject.org. They are updated regularly. If you have a problem, then ask about it.
https://docs.fedoraproject.org/en-US/quick-docs/getting-started-with-apache-...
Avoid off-site answers. Oftentimes it's just dev2dev answers, with some dev posting what worked for him when following someone else's article.
Jeff
On Mon, 2023-04-24 at 12:27 -0400, Jeffrey Walton wrote:
Why? Because being unfamiliar with Apache (and Certbot) I was foolishly following an online step-by-step guide:
https://www.linuxshelltips.com/install-apache-fedora-linux/
I've since seen the error of my ways and it seems to be working now.
Yeah, first try Fedora docs at docs.fedoraproject.org. They are updated regularly. If you have a problem, then ask about it.
https://docs.fedoraproject.org/en-US/quick-docs/getting-started-with-apache-...
Avoid off-site answers. Oftentimes it's just dev2dev answers, with some dev posting what worked for him when following someone else's article.
Thanks.
poc
Once upon a time, Patrick O'Callaghan pocallaghan@gmail.com said:
httpd: could not open error log file /var/www/bree.org.uk/error.log
Putting the log under /var/www is very bad practice, as that could be remotely accessible now (and share all kinds of useful information to attackers). Rather than do that, and disable SELinux protections, you should put your logs under the log directory, /var/log. If you don't like the default permissions on /var/log/httpd, you can make another directory, but still under /var/log (and not accessible over the web).
On 4/23/23 15:08, Chris Adams wrote:
Once upon a time, Patrick O'Callaghan pocallaghan@gmail.com said:
httpd: could not open error log file /var/www/bree.org.uk/error.logPutting the log under /var/www is very bad practice, as that could be remotely accessible now (and share all kinds of useful information to attackers). Rather than do that, and disable SELinux protections, you should put your logs under the log directory, /var/log. If you don't like the default permissions on /var/log/httpd, you can make another directory, but still under /var/log (and not accessible over the web).
Chris and others earlier,
I don't understand how his logs are accessible to the web. They are not under the DocumentRoot. error.log is above it and access.log is next to it. Is it somehow possible for a client to reach above / ?
If so, let me know how. I like to package my VirtualHosts so everything is in one zippable, portable package. If my stuff is in the wind I'll need to make some changes.
path/to/domain/DocRoot path/to/domain/conf path/to/domain/acc (link to /var/log/httpd/domain/access.log) path/to/domain/err (link to /var/log/httpd/domain/error.log)
Thanks in advance, Mike
Once upon a time, Mike Wright nobody@nospam.hostisimo.com said:
I don't understand how his logs are accessible to the web. They are not under the DocumentRoot. error.log is above it and access.log is next to it. Is it somehow possible for a client to reach above / ?
I didn't look at the posted configs (I haven't run Apache in ages, switched to nginx), so I didn't know the DocumentRoot. I just saw the directory path as /var/www/<domain>, which I've seen lots of people use as their DocumentRoot.
Chris Adams wrote:
Once upon a time, Mike Wright nobody@nospam.hostisimo.com said:
I don't understand how his logs are accessible to the web. They are not under the DocumentRoot. error.log is above it and access.log is next to it. Is it somehow possible for a client to reach above / ?
I didn't look at the posted configs (I haven't run Apache in ages, switched to nginx), so I didn't know the DocumentRoot. I just saw the directory path as /var/www/<domain>, which I've seen lots of people use as their DocumentRoot.
It looked odd to me as well. Apparently, the SELinux policy tries to help with such a configuration (though it wouldn't match Patrick's).
Checking the labeling via `semanage fcontext -l` the following patterns are in place (among many others for /var/www/*):
SELinux fcontext type Context =============================================== /var/www(/.*)? all files system_u:object_r:httpd_sys_content_t:s0 /var/www(/.*)?/logs(/.*)? all files system_u:object_r:httpd_log_t:s0
Neither of these would match the log files in the configuration posted earlier:
<VirtualHost *:80> ServerName bree.org.uk ServerAdmin pocallaghan@gmail.com DocumentRoot /var/www/bree.org.uk/html ErrorLog /var/www/bree.org.uk/error.log CustomLog /var/www/bree.org.uk/log/access.log combined </VirtualHost>
So while the logs wouldn't be served up by httpd as part of the document root, they would both be denied by SELinux AFAICT.
Putting them both under /var/www/bree.org.uk/logs/ would help in that respect; though personally I'd put them under /var/log/httpd unless I were running a web hosting service or something¹.
¹ and if I'm ever running a web hosting service, I have likely lost my mind and should be ignored (more so than I am now, if that's possible).
On Sun, 2023-04-23 at 15:29 -0700, Mike Wright wrote:
I don't understand how his logs are accessible to the web. They are not under the DocumentRoot. error.log is above it and access.log is next to it. Is it somehow possible for a client to reach above / ?
Normally, they aren't. But Patrick's were inside it. It may have been possible for them to be publicly seen.
Remember file contexts are created on the file path, by creating a file in the doc root structure, they'd be given public serveable SELinux contexts. And, after switching off SELinux, it was even more likely they could be.
If so, let me know how. I like to package my VirtualHosts so everything is in one zippable, portable package. If my stuff is in the wind I'll need to make some changes.
path/to/domain/DocRoot path/to/domain/conf path/to/domain/acc (link to /var/log/httpd/domain/access.log) path/to/domain/err (link to /var/log/httpd/domain/error.log)
That'd work, too.
On Sun, Apr 23, 2023 at 5:51 PM Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Mon, 2023-04-24 at 05:06 +0930, Tim via users wrote:
On Sun, 2023-04-23 at 12:21 -0700, T.C. Hollingsworth wrote:
Webroot authentication is pretty simple, what trips most people up is it puts it in a dot directory /.well-known/acme-challenge/ and a lot of open source packages include Apache rules that block dotfiles with errors to hide these files so see if you have any rules like that or specifically whitelist that path.
Access to files named like them is still allowed, they're just not shown in automatic directory listings in the browser.
Specific files like .htaccess and .htpasswd ought to be blocked.
I had a look at /var/log/httpd/error_log and found this:
httpd: could not open error log file /var/www/bree.org.uk/error.logI rechecked and that file definitely exists and is writable by root (which httpd runs as). However a suspicion arose and I decided to turn off SElinux and reload.
And it worked. Not only that, but certbot worked as well:
# httpd -t -D DUMP_VHOSTS VirtualHost configuration: *:80 bree.org.uk (/etc/httpd/conf.d/bree.conf:1) *:443 is a NameVirtualHost default server bree.org.uk (/etc/httpd/conf.d/bree-le-ssl.conf:2) port 443 namevhost bree.org.uk (/etc/httpd/conf.d/bree-le-ssl.conf:2) port 443 namevhost bree.org.uk (/etc/httpd/conf.d/ssl.conf:56)
I'm well aware that you had mentioned SElinux earlier, and I had definitely done tests having turned it off, but clearly I missed something.
I may have caused the problem by changing ownership of some files to apache:apache without considering their SElinux context. For the time being I'm keeping setenforce=0 until I can figure this out (suggestions are of course welcome).
Effusive thanks to the multiple people who chipped in with ideas.
I imagine Apache should work out-of-the-box with Fedora. I would be surprised if Fedora shipped a broken one.
This is an unusual place:
> httpd: could not open error log file > /var/www/bree.org.uk/error.log
I don't think that will work.
Move the log file to /var/log, relabel your filesystem, and then reboot:
sudo fixfiles -B onboot
Jeff
On Sun, Apr 23, 2023 at 6:53 PM Jeffrey Walton noloader@gmail.com wrote:
On Sun, Apr 23, 2023 at 5:51 PM Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Mon, 2023-04-24 at 05:06 +0930, Tim via users wrote:
On Sun, 2023-04-23 at 12:21 -0700, T.C. Hollingsworth wrote:
Webroot authentication is pretty simple, what trips most people up is it puts it in a dot directory /.well-known/acme-challenge/ and a lot of open source packages include Apache rules that block dotfiles with errors to hide these files so see if you have any rules like that or specifically whitelist that path.
Access to files named like them is still allowed, they're just not shown in automatic directory listings in the browser.
Specific files like .htaccess and .htpasswd ought to be blocked.
I had a look at /var/log/httpd/error_log and found this:
httpd: could not open error log file /var/www/bree.org.uk/error.logI rechecked and that file definitely exists and is writable by root (which httpd runs as). However a suspicion arose and I decided to turn off SElinux and reload.
And it worked. Not only that, but certbot worked as well:
# httpd -t -D DUMP_VHOSTS VirtualHost configuration: *:80 bree.org.uk (/etc/httpd/conf.d/bree.conf:1) *:443 is a NameVirtualHost default server bree.org.uk (/etc/httpd/conf.d/bree-le-ssl.conf:2) port 443 namevhost bree.org.uk (/etc/httpd/conf.d/bree-le-ssl.conf:2) port 443 namevhost bree.org.uk (/etc/httpd/conf.d/ssl.conf:56)
I'm well aware that you had mentioned SElinux earlier, and I had definitely done tests having turned it off, but clearly I missed something.
I may have caused the problem by changing ownership of some files to apache:apache without considering their SElinux context. For the time being I'm keeping setenforce=0 until I can figure this out (suggestions are of course welcome).
Effusive thanks to the multiple people who chipped in with ideas.
I imagine Apache should work out-of-the-box with Fedora. I would be surprised if Fedora shipped a broken one.
This is an unusual place:
> httpd: could not open error log file > /var/www/bree.org.uk/error.logI don't think that will work.
Move the log file to /var/log, relabel your filesystem, and then reboot:
sudo fixfiles -B onboot
And to expand on this... Under SELinux, the log location needs a httpd_log_t context:
# ls -AlZ /var/log/ | grep -i -E 'apache|nginx' drwx--x--x. 2 root root system_u:object_r:httpd_log_t:s0 4096 Apr 10 20:00 nginx
Relabeling should fix it.
Jeff
On Sun, 2023-04-23 at 18:58 -0400, Jeffrey Walton wrote:
On Sun, Apr 23, 2023 at 6:53 PM Jeffrey Walton noloader@gmail.com wrote:
On Sun, Apr 23, 2023 at 5:51 PM Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Mon, 2023-04-24 at 05:06 +0930, Tim via users wrote:
On Sun, 2023-04-23 at 12:21 -0700, T.C. Hollingsworth wrote:
Webroot authentication is pretty simple, what trips most people up is it puts it in a dot directory /.well-known/acme-challenge/ and a lot of open source packages include Apache rules that block dotfiles with errors to hide these files so see if you have any rules like that or specifically whitelist that path.
Access to files named like them is still allowed, they're just not shown in automatic directory listings in the browser.
Specific files like .htaccess and .htpasswd ought to be blocked.
I had a look at /var/log/httpd/error_log and found this:
httpd: could not open error log file /var/www/bree.org.uk/error.log
I rechecked and that file definitely exists and is writable by root (which httpd runs as). However a suspicion arose and I decided to turn off SElinux and reload.
And it worked. Not only that, but certbot worked as well:
# httpd -t -D DUMP_VHOSTS VirtualHost configuration: *:80 bree.org.uk (/etc/httpd/conf.d/bree.conf:1) *:443 is a NameVirtualHost default server bree.org.uk (/etc/httpd/conf.d/bree-le- ssl.conf:2) port 443 namevhost bree.org.uk (/etc/httpd/conf.d/bree- le-ssl.conf:2) port 443 namevhost bree.org.uk (/etc/httpd/conf.d/ssl.conf:56)
I'm well aware that you had mentioned SElinux earlier, and I had definitely done tests having turned it off, but clearly I missed something.
I may have caused the problem by changing ownership of some files to apache:apache without considering their SElinux context. For the time being I'm keeping setenforce=0 until I can figure this out (suggestions are of course welcome).
Effusive thanks to the multiple people who chipped in with ideas.
I imagine Apache should work out-of-the-box with Fedora. I would be surprised if Fedora shipped a broken one.
This is an unusual place:
> httpd: could not open error log file > /var/www/bree.org.uk/error.log
I don't think that will work.
Move the log file to /var/log, relabel your filesystem, and then reboot:
sudo fixfiles -B onboot
And to expand on this... Under SELinux, the log location needs a httpd_log_t context:
# ls -AlZ /var/log/ | grep -i -E 'apache|nginx' drwx--x--x. 2 root root system_u:object_r:httpd_log_t:s0 4096 Apr 10 20:00 nginx
Relabeling should fix it.
I've done that (i.e. moved things back to the more usual /var/www and /var/log directories, and relabelled. Seems to work now.
I had originally been following an online guide which gave the more complicated setup rather than the default. That'll teach me to run before I can walk.
Thanks
poc
Tim:
If you browse to http://bree.org.uk/%C2%A0and%C2%A0https://bree.org.uk/ do you get the same results?
Patrick O'Callaghan:
Internally, yes.
I forgot to mention: You should switch off any HTTPS-only browser plug-ins (if you have any), while doing this kind of test. It's only going to add more nuisances to the testing.
If I try web browsing your site, I get the same "books" page to either address. There is a HTTPS connection, but it complains it's not secure. There's no obvious indication about who issued the certificate.
There is no certificate.
There was. I could see basic details about it.
When I tried just now, trying to load the HTTP site immediately bounces me to the HTTPS site, which doesn't load.
Remember when playing with Apache, you can set up your own configs in /etc/httpd/conf.d *and* there are some pre-supplied example files.
I get similar HTTPS basic cert info from the supplied conf.d/ssl.conf file on my server.
One suggested approach is that you make a yourwebsite.conf file to go in there, and put all your site config options (HTTP, HTTPS, file access) into it. For the convenience sake of one personal file for you, and keeping an unmangled basic httpd.conf file. Which was the way you went, according to your other comments.
If you only have one site, you may as well do everything in the main /etc/httpd/conf/httpd.conf file, if you want. It may be less confusing if you don't have to check for conflicting options across different files.
Remember HTTPS is configured separately from HTTP.
You may want to move all/most of the pre-supplied conf.d/ files out of the way (or check each one first, to see whether it's best left there, or shifted out of the way).
The reason I suspect an Apache problem is as follows: when I configured the VirtualHost, it was via an included file:
# pwd /etc/httpd/conf.d [root@Bree conf.d]# cat bree.conf <VirtualHost *:80> ServerName bree.org.uk ServerAdmin pocallaghan@gmail.com DocumentRoot /var/www/bree.org.uk/html ErrorLog /var/www/bree.org.uk/error.log CustomLog /var/www/bree.org.uk/log/access.log combined
</VirtualHost> # tail -2 ../conf/httpd.conf # Load config files in the "/etc/httpd/conf.d" directory, if any. IncludeOptional conf.d/*.conf
About the only thing different from that, in mine, is I have
UseCanonicalName On
as well. The idea is that any internal site redirects, such as when the server does a directory listing for a folder instead of serving a HTML file in it, the browser will come back with a page using your server name if it didn't already (such as browsing by IP address). I think it may also change browsing by the ServerAlias over to using the ServerName.
Did you look in the access and error logs for clues?
Bear in mind that's the HTTP site details, the HTTPS site config is separate. You may still have the example conf.d/ssl.conf file interfering with your tests.
Now when I start Apache I get: # apachectl restart Job for httpd.service failed because the control process exited with error code. See "systemctl status httpd.service" and "journalctl -xeu httpd.service" for details.
The only warning in the journal is: Failed to start httpd.service - The Apache HTTP Server.
Nothing else interspersed in an odd place?
I still use /var/log/messages. It's more straight-forward to me, and I can see interactions between other things as well as what I'm trying to debug.
IOW Apache simply fails to start when I try to use the VirtualHost directive, but provides no useful information. Furthermore: # httpd -t -D DUMP_HOSTS Syntax OK #
So Apache itself says there is no syntax error in the file(s).
No *detected* error... :-/
You could have something that's not technically a syntax error, but isn't making your site work in the expected way (for you).
So why do I say that I can browse to port 80? Because when I *don't* include that bree.conf file, everything starts up and runs. Therefore the problem logically is in that file, but despite careful scanning of the Apache docs I can't see what it is. Note that the various files referenced in bree.conf all exist and are world-readable:
# ls -l /var/www/bree.org.uk/html total 4 -rwxr-xr-x. 1 apache apache 159 Apr 16 22:24 index.html [root@Bree conf.d]# ls -l /var/www/bree.org.uk/error.log -rw-r--r--. 1 root root 0 Apr 21 22:28 /var/www/bree.org.uk/error.log [root@Bree conf.d]# ls -l /var/www/bree.org.uk/log/access.log ls: cannot access '/var/www/bree.org.uk/log/access.log': No such file or directory [root@Bree conf.d]# ls -l /var/www/bree.org.uk/log total 0
Hmm, if there's 0 byte files, or no files, that would either indicate no activity, or log rotation has occurred.
In my configuration, logs are not in those paths, there's subdirectories inside these per site.
Logs: /var/log/httpd/ Sites: /var/www/
*I* wouldn't want my logs inside the web serving tree.
Are all your filepaths correct?
On Sun, Apr 23, 2023 at 3:20 PM Tim via users users@lists.fedoraproject.org wrote:
[...]
not secure. There's no obvious indication about who issued the certificate.
There is no certificate.
There was. I could see basic details about it.
Yeah, it does not look like there's a listener on 443 at the moment:
$ openssl s_client -connect bree.org.uk:443 -servername bree.org.uk 402760D1707F0000:error:8000006F:system library:BIO_connect:Connection refused:../crypto/bio/bio_sock2.c:125:calling connect() 402760D1707F0000:error:10000067:BIO routines:BIO_connect:connect error:../crypto/bio/bio_sock2.c:127: connect:errno=111
Jeff
On Sat, 2023-04-22 at 13:11 +0100, Patrick O'Callaghan wrote:
I'm trying to set up a simple web server for personal use, using Apache, and want to enable HTTPS access. This involves getting an SSL certificate and I'll be using LetsEncrypt (www.letsencrypt.org).
The recommended way to do this is with Certbot, but I can't get past this error:
# certbot --apache -d bree.org.uk Saving debug log to /var/log/letsencrypt/letsencrypt.log Requesting a certificate for bree.org.uk Unable to find a virtual host listening on port 80 which is currently needed for Certbot to prove to the CA that you control your domain. Please add a virtual host for port 80. Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
Note that the httpd server is online and reachable from outside my local net, i.e. this doesn't appear to be a firewall issue.
I've reported the problem upstream and followed a number of suggestions, but nothing seems to make any difference:
https://community.letsencrypt.org/t/certbot-fails-with-cant-find-virtual-hos...
I wonder does Certbot read the Apache config files directly, or is it doing HTTP/HTTPS access of the webserver?
Looking at some of your results it is probing port 80, though it might be doing more than one thing.
Assuming that Certbot runs inside your LAN, does the domain name resolve internally to an IP that can be reached internally?
e.g. Can you browse to that address staying entirely within your LAN?
If it reads the config files, might SELinux be denying it?
Looking at my Apache configuration, the virtual hosts ServerName and ServerAlias entries just have the host names without any port numbers.
<VirtualHost *:80> ServerName www.example.com ServerAlias example.com
Interesting that it wants a port 80 virtual host, for something (HTTPS) that's going to be running through port 443. I would have thought you'd need something along the lines of:
<VirtualHost *:443> ServerName www.example.com ServerAlias example.com
as well.
I have to say that my experimenting with SSL is rather limited, I don't have anything needing encryption on my public or private web servers. And the public one is professionally hosted, where they've done most of the hard work, and customising it is next to impossible (regarding the issues we're discussing here).
On Sun, 2023-04-23 at 00:26 +0930, Tim via users wrote:
On Sat, 2023-04-22 at 13:11 +0100, Patrick O'Callaghan wrote:
I'm trying to set up a simple web server for personal use, using Apache, and want to enable HTTPS access. This involves getting an SSL certificate and I'll be using LetsEncrypt (www.letsencrypt.org).
The recommended way to do this is with Certbot, but I can't get past this error:
# certbot --apache -d bree.org.uk Saving debug log to /var/log/letsencrypt/letsencrypt.log Requesting a certificate for bree.org.uk Unable to find a virtual host listening on port 80 which is currently needed for Certbot to prove to the CA that you control your domain. Please add a virtual host for port 80. Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
Note that the httpd server is online and reachable from outside my local net, i.e. this doesn't appear to be a firewall issue.
I've reported the problem upstream and followed a number of suggestions, but nothing seems to make any difference:
https://community.letsencrypt.org/t/certbot-fails-with-cant-find-virtual-hos...
I wonder does Certbot read the Apache config files directly, or is it doing HTTP/HTTPS access of the webserver?
Looking at some of your results it is probing port 80, though it might be doing more than one thing.
Assuming that Certbot runs inside your LAN, does the domain name resolve internally to an IP that can be reached internally?
Yes.
e.g. Can you browse to that address staying entirely within your LAN?
Yes.
If it reads the config files, might SELinux be denying it?
No. I disabled SElinux and it made no difference.
Looking at my Apache configuration, the virtual hosts ServerName and ServerAlias entries just have the host names without any port numbers.
<VirtualHost *:80> ServerName www.example.com ServerAlias example.com
The port number is optional. I've since removed it. It makes no difference.
Interesting that it wants a port 80 virtual host, for something (HTTPS) that's going to be running through port 443. I would have thought you'd need something along the lines of:
<VirtualHost *:443> ServerName www.example.com ServerAlias example.com
as well.
My understanding is that it needs port 80 for the initial token negotiation to get the certificate to set up HTTPS. Requiring port 443 would be a circular dependency.
poc
On Sat, 2023-04-22 at 18:45 +0100, Patrick O'Callaghan wrote:
My understanding is that it needs port 80 for the initial token negotiation to get the certificate to set up HTTPS. Requiring port 443 would be a circular dependency.
So far as I'm aware, that's not the case. A HTTPS connection is made completely over port 443. The browser attempts to connect directly to port 443, and negotiation for *how* to do that carries on over port 443. To attempt to non-securely start this over port 80 would be insecure.
And, testing that: If I disable all port 80 connections, I can connect to my webserver using HTTPS over port 443.
Their error message seems to indicate that *it* wants a connection response from the webserver on port 80 with your site's domain name in the response headers (to prove you own the site). This seems to be a bizarre requirement. Possibly the cert checker needs programming better, rather than Apache needing something done to it.
Nor should you really have to have a virtual host. You could be a webserver that you own totally and it only serves your website. It seems some oddball demands from the cert checker.
My thoughts are that cert testing should be done entirely over port 443. Since that's how HTTPS works, the test should work the same way. A HTTP transaction over port 80 wouldn't have any info about the HTTPS certificate.
On Sun, 2023-04-23 at 06:47 +0930, Tim via users wrote:
On Sat, 2023-04-22 at 18:45 +0100, Patrick O'Callaghan wrote:
My understanding is that it needs port 80 for the initial token negotiation to get the certificate to set up HTTPS. Requiring port 443 would be a circular dependency.
[...]
And, testing that: If I disable all port 80 connections, I can connect to my webserver using HTTPS over port 443.
Their error message seems to indicate that *it* wants a connection response from the webserver on port 80 with your site's domain name in the response headers (to prove you own the site). This seems to be a bizarre requirement. Possibly the cert checker needs programming better, rather than Apache needing something done to it.
That's entirely possible of course.
Nor should you really have to have a virtual host. You could be a webserver that you own totally and it only serves your website. It seems some oddball demands from the cert checker.
I do agree with that. I think it's a specific limitation of Certbot itself, which (from discussions on the LetsEncrypt site) actually messes with your Apache config while it's doing its testing. Other implementations of the ACME protocol don't seem to require this, but I'm just guessing.
poc
On 4/22/23 14:30, Patrick O'Callaghan wrote:
On Sun, 2023-04-23 at 06:47 +0930, Tim via users wrote:
On Sat, 2023-04-22 at 18:45 +0100, Patrick O'Callaghan wrote:
My understanding is that it needs port 80 for the initial token negotiation to get the certificate to set up HTTPS. Requiring port 443 would be a circular dependency.
[...]
And, testing that: If I disable all port 80 connections, I can connect to my webserver using HTTPS over port 443.
Their error message seems to indicate that *it* wants a connection response from the webserver on port 80 with your site's domain name in the response headers (to prove you own the site). This seems to be a bizarre requirement. Possibly the cert checker needs programming better, rather than Apache needing something done to it.
That's entirely possible of course.
Nor should you really have to have a virtual host. You could be a webserver that you own totally and it only serves your website. It seems some oddball demands from the cert checker.
I do agree with that. I think it's a specific limitation of Certbot itself, which (from discussions on the LetsEncrypt site) actually messes with your Apache config while it's doing its testing. Other implementations of the ACME protocol don't seem to require this, but I'm just guessing.
There are other methods. You can tell it where the webroot is (as described by Markus), you can have certbot run its own web server, you can use a DNS entry, etc.
On 4/22/23 14:17, Tim via users wrote:
On Sat, 2023-04-22 at 18:45 +0100, Patrick O'Callaghan wrote:
My understanding is that it needs port 80 for the initial token negotiation to get the certificate to set up HTTPS. Requiring port 443 would be a circular dependency.
So far as I'm aware, that's not the case. A HTTPS connection is made completely over port 443. The browser attempts to connect directly to port 443, and negotiation for *how* to do that carries on over port 443. To attempt to non-securely start this over port 80 would be insecure.
And, testing that: If I disable all port 80 connections, I can connect to my webserver using HTTPS over port 443.
Their error message seems to indicate that *it* wants a connection response from the webserver on port 80 with your site's domain name in the response headers (to prove you own the site). This seems to be a bizarre requirement. Possibly the cert checker needs programming better, rather than Apache needing something done to it.
Nor should you really have to have a virtual host. You could be a webserver that you own totally and it only serves your website. It seems some oddball demands from the cert checker.
My thoughts are that cert testing should be done entirely over port 443. Since that's how HTTPS works, the test should work the same way. A HTTP transaction over port 80 wouldn't have any info about the HTTPS certificate.
As Patrick said, using port 443 would be a circular dependency. There is no "testing" of the cert, this is for providing the cert. At this point, you don't have an SSL certificate, so it wouldn't work. The requester puts a token in the web server directory and then tells the certificate generating side to verify the token. To do that, it has to request that file from your domain and compare it to what the requester gave it. The requirements are that your domain name resolves to an address that points to the http server serving that file. There is also an alternative method where you put the token in a DNS entry instead. That's useful for when the cert is for a not publicly visible server.
On Sat, 2023-04-22 at 14:32 -0700, Samuel Sieb wrote:
As Patrick said, using port 443 would be a circular dependency. There is no "testing" of the cert, this is for providing the cert.
Ah... I thought it was for checking and auto-renewing certificates before expiry (like certwatch).
At this point, you don't have an SSL certificate, so it wouldn't work. The requester puts a token in the web server directory and then tells the certificate generating side to verify the token.
Hmm, sounds like a security problem to get data via insecure means, in the first place. It escapes me why you'd want to work that way if you were running it on the same machine as the server.
On 4/22/23 15:11, Tim via users wrote:
On Sat, 2023-04-22 at 14:32 -0700, Samuel Sieb wrote:
As Patrick said, using port 443 would be a circular dependency. There is no "testing" of the cert, this is for providing the cert.
Ah... I thought it was for checking and auto-renewing certificates before expiry (like certwatch).
At this point, you don't have an SSL certificate, so it wouldn't work. The requester puts a token in the web server directory and then tells the certificate generating side to verify the token.
Hmm, sounds like a security problem to get data via insecure means, in the first place. It escapes me why you'd want to work that way if you were running it on the same machine as the server.
How is it insecure? The requester creates a one-time token, passes that to the letsencrypt server. The server connects back using the domain name to make sure the domain and request is valid by checking the token. There's no way to mitm that.
On Sat, Apr 22, 2023 at 6:12 PM Tim via users users@lists.fedoraproject.org wrote:
On Sat, 2023-04-22 at 14:32 -0700, Samuel Sieb wrote:
As Patrick said, using port 443 would be a circular dependency. There is no "testing" of the cert, this is for providing the cert.
Ah... I thought it was for checking and auto-renewing certificates before expiry (like certwatch).
At this point, you don't have an SSL certificate, so it wouldn't work. The requester puts a token in the web server directory and then tells the certificate generating side to verify the token.
Hmm, sounds like a security problem to get data via insecure means, in the first place. It escapes me why you'd want to work that way if you were running it on the same machine as the server.
The LE client downloads a X.509 certificate based on a CSR (after passing the challenges). It's the same certificate the server supplies to user agents and clients. There's no loss of confidentiality.
About the only thing an adversary can do is a DoS.
Jeff
Tim:
Nor should you really have to have a virtual host.
Mike Wright:
I think it may be referring to the Apache directive <VirtualHost *>
So was I. You can have a webserver serving a solitary website. Virtual host configs should only be necessary when you have multiple sites on the same server.
Really, it ought to be looking for the server name (and/or aliases), and the server should be sending them back with all connection attempts (including when you don't do virtual hosting). It's just that virtual host configuration is much more explicit about getting you to configure it.
It used to be that HTTPS required that (dedicated server), which was a problem in a world with dwindling spare IPv4 addresses.
On Sat, 2023-04-22 at 16:02 -0700, Mike Wright wrote:
On 4/22/23 14:17, Tim via users wrote:
<snip/> > > Nor should you really have to have a virtual host.
I think it may be referring to the Apache directive <VirtualHost *>
AFAIK this is a limitation specific to Certbot. It's not fundamental to how the ACME protocol works.
poc
On 4/22/23 05:11, Patrick O'Callaghan wrote:
I'm trying to set up a simple web server for personal use, using Apache, and want to enable HTTPS access. This involves getting an SSL certificate and I'll be using LetsEncrypt (www.letsencrypt.org).
The recommended way to do this is with Certbot, but I can't get past this error:
# certbot --apache -d bree.org.uk Saving debug log to /var/log/letsencrypt/letsencrypt.log Requesting a certificate for bree.org.uk Unable to find a virtual host listening on port 80 which is currently needed for Certbot to prove to the CA that you control your domain. Please add a virtual host for port 80. Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
Note that the httpd server is online and reachable from outside my local net, i.e. this doesn't appear to be a firewall issue.
I've reported the problem upstream and followed a number of suggestions, but nothing seems to make any difference:
https://community.letsencrypt.org/t/certbot-fails-with-cant-find-virtual-hos...
Any thoughts on this would be welcome, but please review the above link before replying.
poc _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 4/22/23 05:11, Patrick O'Callaghan wrote:
I'm trying to set up a simple web server for personal use, using Apache, and want to enable HTTPS access. This involves getting an SSL certificate and I'll be using LetsEncrypt (www.letsencrypt.org).
The recommended way to do this is with Certbot, but I can't get past this error:
# certbot --apache -d bree.org.uk Saving debug log to /var/log/letsencrypt/letsencrypt.log Requesting a certificate for bree.org.uk Unable to find a virtual host listening on port 80 which is currently needed for Certbot to prove to the CA that you control your domain. Please add a virtual host for port 80. Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
Note that the httpd server is online and reachable from outside my local net, i.e. this doesn't appear to be a firewall issue.
I've reported the problem upstream and followed a number of suggestions, but nothing seems to make any difference:
https://community.letsencrypt.org/t/certbot-fails-with-cant-find-virtual-hos...
Any thoughts on this would be welcome, but please review the above link before replying.
Trying again. The "Dark" theme gave me purple on black. Looks like nobody can see what I wrote ;/
I've never seen the port number included as part of the ServerName directive. Try removing that and give it a go.
Mike Wright wrote:
I've never seen the port number included as part of the ServerName directive. Try removing that and give it a go.
FWIW, the documented syntax¹ for ServerName is:
ServerName [scheme://]domain-name|ip-address[:port]
That docs go on to say:
If no port is specified in the ServerName, then the server will use the port from the incoming request. For optimal reliability and predictability, you should specify an explicit hostname and port using the ServerName directive.
Having a port in ServerName shouldn't be a problem (assuming the correct port, of course).
¹ https://httpd.apache.org/docs/2.4/mod/core.html#servername
On 4/22/23 10:26, Todd Zullinger wrote:
Mike Wright wrote:
I've never seen the port number included as part of the ServerName directive. Try removing that and give it a go.
FWIW, the documented syntax¹ for ServerName is:
ServerName [scheme://]domain-name|ip-address[:port]That docs go on to say:
If no port is specified in the ServerName, then the server will use the port from the incoming request. For optimal reliability and predictability, you should specify an explicit hostname and port using the ServerName directive.Having a port in ServerName shouldn't be a problem (assuming the correct port, of course).
¹ https://httpd.apache.org/docs/2.4/mod/core.html#servername
Thanks Todd,
I'd always taken ServerName literally and had no idea it allowed such granularity. With the ability to also specify protocol allows (e.g.) having different DocumentRoot values for ftp, http, https, etc.
Nice.
Mike
On Sat, 2023-04-22 at 09:24 -0700, Mike Wright wrote:
On 4/22/23 05:11, Patrick O'Callaghan wrote:
I'm trying to set up a simple web server for personal use, using Apache, and want to enable HTTPS access. This involves getting an SSL certificate and I'll be using LetsEncrypt (www.letsencrypt.org).
The recommended way to do this is with Certbot, but I can't get past this error:
# certbot --apache -d bree.org.uk Saving debug log to /var/log/letsencrypt/letsencrypt.log Requesting a certificate for bree.org.uk Unable to find a virtual host listening on port 80 which is currently needed for Certbot to prove to the CA that you control your domain. Please add a virtual host for port 80. Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
Note that the httpd server is online and reachable from outside my local net, i.e. this doesn't appear to be a firewall issue.
I've reported the problem upstream and followed a number of suggestions, but nothing seems to make any difference:
https://community.letsencrypt.org/t/certbot-fails-with-cant-find-virtual-hos...
Any thoughts on this would be welcome, but please review the above link before replying.
Trying again. The "Dark" theme gave me purple on black. Looks like nobody can see what I wrote ;/
I've never seen the port number included as part of the ServerName directive. Try removing that and give it a go.
The port number is optional, according to the docs. However that was a late addition. Previously I didn't have it and it made no difference. I've since removed it.
poc
Am 22.04.2023 um 14:11 schrieb Patrick O'Callaghan pocallaghan@gmail.com:
I'm trying to set up a simple web server for personal use, using Apache, and want to enable HTTPS access. This involves getting an SSL certificate and I'll be using LetsEncrypt (www.letsencrypt.org).
The recommended way to do this is with Certbot, but I can't get past this error:
With apache you have the advantage that you don't need certbot at all, but apache does everything itself with the help of the md module. Configure as follows:
# Letsencrypt certificate management via Apache mod_md # By default, automatically all alternative names get included. MDomain MY_DOMAIN.TLD MDContactEmail ME@MY_DOMAIN.TLD MDCertificateAgreement accepted <VirtualHost *:443> ServerName MY_DOMAIN.TLD ServerAlias www.MY_DOMAIN.TLD ServerAlias demo.MY_DOMAIN.TLD … … </VirtualHost>
After adding the above configuration restart apache. Wait some minutes and restart again. You should now see in the logs the certificates.
Apache cares about the 3-monthly renewing. You don’t need to do anything.
-- Peter Boy https://fedoraproject.org/wiki/User:Pboy pboy@fedoraproject.org
Timezone: CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member Fedora docs team contributor Java developer and enthusiast
On Sat, 2023-04-22 at 18:27 +0200, Peter Boy wrote:
Am 22.04.2023 um 14:11 schrieb Patrick O'Callaghan pocallaghan@gmail.com:
I'm trying to set up a simple web server for personal use, using Apache, and want to enable HTTPS access. This involves getting an SSL certificate and I'll be using LetsEncrypt (www.letsencrypt.org).
The recommended way to do this is with Certbot, but I can't get past this error:
With apache you have the advantage that you don't need certbot at all, but apache does everything itself with the help of the md module. Configure as follows:
# Letsencrypt certificate management via Apache mod_md # By default, automatically all alternative names get included. MDomain MY_DOMAIN.TLD MDContactEmail ME@MY_DOMAIN.TLD MDCertificateAgreement accepted <VirtualHost *:443> ServerName MY_DOMAIN.TLD ServerAlias www.MY_DOMAIN.TLD ServerAlias demo.MY_DOMAIN.TLD … …
</VirtualHost>
After adding the above configuration restart apache. Wait some minutes and restart again. You should now see in the logs the certificates.
Apache cares about the 3-monthly renewing. You don’t need to do anything.
That's interesting, but seems to contradict what the LetsEncrypt site seems to say (as far as I understand it). How does Apache set up a certificate if it's only reachable via port 443, which requires a certificate?
poc
Am 22.04.2023 um 19:48 schrieb Patrick O'Callaghan pocallaghan@gmail.com:
On Sat, 2023-04-22 at 18:27 +0200, Peter Boy wrote:
Am 22.04.2023 um 14:11 schrieb Patrick O'Callaghan pocallaghan@gmail.com:
I'm trying to set up a simple web server for personal use, using Apache, and want to enable HTTPS access. This involves getting an SSL certificate and I'll be using LetsEncrypt (www.letsencrypt.org).
The recommended way to do this is with Certbot, but I can't get past this error:
With apache you have the advantage that you don't need certbot at all, but apache does everything itself with the help of the md module. Configure as follows:
# Letsencrypt certificate management via Apache mod_md # By default, automatically all alternative names get included. MDomain MY_DOMAIN.TLD MDContactEmail ME@MY_DOMAIN.TLD MDCertificateAgreement accepted <VirtualHost *:443> ServerName MY_DOMAIN.TLD ServerAlias www.MY_DOMAIN.TLD ServerAlias demo.MY_DOMAIN.TLD … …
</VirtualHost>
After adding the above configuration restart apache. Wait some minutes and restart again. You should now see in the logs the certificates.
Apache cares about the 3-monthly renewing. You don’t need to do anything.
That's interesting, but seems to contradict what the LetsEncrypt site seems to say (as far as I understand it). How does Apache set up a certificate if it's only reachable via port 443, which requires a certificate?
Apache developed mod_md which is, among others, yet another implementation of the certbot protocol, but manages everything inside apache. The module knows it has to renew every 3 months and it manages the communication with lets encrypt by its own. I didn’t check, but - as it works - mod_md knows about the ports and chooses the appropriate.
I should have send the complete config, it says further down:
<VirtualHost *:80> # Production Web Site Fiction meets Science ServerName MY_DOMAIN.TLD ServerAlias www.MY_DOMAIN.TLD RewriteEngine On RewriteRule ^(.*)$ https://MY_DOMAIN.TLD$1 [R=301,L] </VirtualHost>
But of course, I use Fedora Server.
-- Peter Boy https://fedoraproject.org/wiki/User:Pboy pboy@fedoraproject.org
Timezone: CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member Fedora docs team contributor Java developer and enthusiast
On Sat, 2023-04-22 at 20:35 +0200, Peter Boy wrote:
Am 22.04.2023 um 19:48 schrieb Patrick O'Callaghan pocallaghan@gmail.com:
On Sat, 2023-04-22 at 18:27 +0200, Peter Boy wrote:
Am 22.04.2023 um 14:11 schrieb Patrick O'Callaghan pocallaghan@gmail.com:
I'm trying to set up a simple web server for personal use, using Apache, and want to enable HTTPS access. This involves getting an SSL certificate and I'll be using LetsEncrypt (www.letsencrypt.org).
The recommended way to do this is with Certbot, but I can't get past this error:
With apache you have the advantage that you don't need certbot at all, but apache does everything itself with the help of the md module. Configure as follows:
# Letsencrypt certificate management via Apache mod_md # By default, automatically all alternative names get included. MDomain MY_DOMAIN.TLD MDContactEmail ME@MY_DOMAIN.TLD MDCertificateAgreement accepted <VirtualHost *:443> ServerName MY_DOMAIN.TLD ServerAlias www.MY_DOMAIN.TLD ServerAlias demo.MY_DOMAIN.TLD … …
</VirtualHost>
After adding the above configuration restart apache. Wait some minutes and restart again. You should now see in the logs the certificates.
Apache cares about the 3-monthly renewing. You don’t need to do anything.
That's interesting, but seems to contradict what the LetsEncrypt site seems to say (as far as I understand it). How does Apache set up a certificate if it's only reachable via port 443, which requires a certificate?
Apache developed mod_md which is, among others, yet another implementation of the certbot protocol, but manages everything inside apache. The module knows it has to renew every 3 months and it manages the communication with lets encrypt by its own. I didn’t check, but - as it works - mod_md knows about the ports and chooses the appropriate.
I should have send the complete config, it says further down:
<VirtualHost *:80> # Production Web Site Fiction meets Science ServerName MY_DOMAIN.TLD ServerAlias www.MY_DOMAIN.TLD RewriteEngine On RewriteRule ^(.*)$ https://MY_DOMAIN.TLD$1%C2%A0 [R=301,L]
</VirtualHost>
It's documented in https://httpd.apache.org/docs/2.4/mod/mod_md.html so I may try it.
poc
On 4/22/23, Patrick O'Callaghan pocallaghan@gmail.com wrote:
How does Apache set up a certificate if it's only reachable via port 443, which requires a certificate?
It uses the ALPN feature of SSL/TLS that is ordinarily used to allow clients to select HTTP 2 over the default HTTP 1 to instead allow the Let's Encrypt service to select their special verification protocol so it doesn't interrupt normal traffic. Then your server will send a fake certificate that includes the verification token from Let's Encrypt since you won't have a real certificate yet.
They used to use the SNI feature that allows clients to select one of multiple hostnames under one IP address using an obviously invalid hostname to trigger the fake certificate, but they later discovered far too many web hosters allowed people to configure their servers for any old domain name, even their invalid scheme, and thus issue certificates for any other customers domains on the same IP address, so they had to make it a little more complicated.
On 4/22/23 09:27, Peter Boy wrote:
With apache you have the advantage that you don't need certbot at all, but apache does everything itself with the help of the md module. Configure as follows:
# Letsencrypt certificate management via Apache mod_md # By default, automatically all alternative names get included. MDomain MY_DOMAIN.TLD MDContactEmail ME@MY_DOMAIN.TLD MDCertificateAgreement accepted <VirtualHost *:443> ServerName MY_DOMAIN.TLD ServerAlias www.MY_DOMAIN.TLD ServerAlias demo.MY_DOMAIN.TLD … …
</VirtualHost>
After adding the above configuration restart apache. Wait some minutes and restart again. You should now see in the logs the certificates.
Apache cares about the 3-monthly renewing. You don’t need to do anything.
That is very nice! Unfortunately, that doesn't work for all my certs because some are for the mail server and other applications, but definitely something to keep in mind for some of them.
On Sat, Apr 22, 2023 at 8:13 AM Patrick O'Callaghan pocallaghan@gmail.com wrote:
I'm trying to set up a simple web server for personal use, using Apache, and want to enable HTTPS access. This involves getting an SSL certificate and I'll be using LetsEncrypt (www.letsencrypt.org).
The recommended way to do this is with Certbot, but I can't get past this error:
# certbot --apache -d bree.org.uk Saving debug log to /var/log/letsencrypt/letsencrypt.log Requesting a certificate for bree.org.uk Unable to find a virtual host listening on port 80 which is currently needed for Certbot to prove to the CA that you control your domain. Please add a virtual host for port 80. Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
Note that the httpd server is online and reachable from outside my local net, i.e. this doesn't appear to be a firewall issue.
I've reported the problem upstream and followed a number of suggestions, but nothing seems to make any difference:
https://community.letsencrypt.org/t/certbot-fails-with-cant-find-virtual-hos...
Any thoughts on this would be welcome, but please review the above link before replying.
No. If there's information needed, it needs to be provided here. I'm not going to grind through some off-site Q&A.
We run an Apache server on Ubuntu 22.04, and we use Certbot for cryptopp.com. (Our VPS host does not provide Fedora Server, so we use Ubuntu Server).
Our server config files are as follows. The first two are most important:
~# find /etc/ -name 'cryptopp*' /etc/apache2/sites-enabled/cryptopp.conf /etc/apache2/sites-available/cryptopp.conf /etc/ssl/private/cryptopp-com.chain.pem /etc/ssl/private/cryptopp-com.pem.rsa /etc/ssl/private/cryptopp-com.key.pem.ec /etc/ssl/private/cryptopp-com.cert.pem /etc/ssl/private/cryptopp-com.chain.pem.rsa /etc/ssl/private/cryptopp-com.key.pem /etc/ssl/private/cryptopp-com.key.pem.rsa
So the question is, do you have a *.conf file in sites-available? And is there a link to it in sites-enabled?
(You enable a site with a2ensite. Once enabled, there is a symlink from sites-available to sites-enabled).
Jeff
========================================
Here is sites-enabled. It is a symlink:
# ls -Al /etc/apache2/sites-enabled/cryptopp.conf lrwxrwxrwx 1 root root 32 Apr 6 2021 /etc/apache2/sites-enabled/cryptopp.conf -> ../sites-available/cryptopp.conf
Here is sites-available/cryptopp.conf:
# cat /etc/apache2/sites-available/cryptopp.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
ServerName cryptopp.com ServerAlias www.cryptopp.com *.cryptopp.com
# https://linuxize.com/post/redirect-http-to-https-in-apache/ Redirect permanent / https://cryptopp.com/
ServerAdmin webmaster@cryptopp.com DocumentRoot /var/www/html
# 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 </VirtualHost>
<VirtualHost *:443>
# SSL Engine Switch: # Enable/Disable SSL for this virtual host. SSLEngine on
ServerName cryptopp.com ServerAlias www.cryptopp.com *.cryptopp.com
ServerAdmin webmaster@cryptopp.com DocumentRoot /var/www/html
# Use separate log files for the SSL virtual host; note that LogLevel # is not inherited from httpd.conf. ErrorLog ${APACHE_LOG_DIR}/error.log TransferLog ${APACHE_LOG_DIR}/access.log LogLevel warn
# SSL Protocol support: # List the enable protocol levels with which clients will be able to # connect. Disable SSLv2 access by default: # SSLProtocol all -SSLv2 SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2 +TLSv1.3
# SSL Cipher Suite: # List the ciphers that the client is permitted to negotiate. # See the mod_ssl documentation for a complete list. # SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5 SSLCipherSuite HIGH:!aNULL:!kRSA:!MD5:!RC4
# We are always going to be better configured than most user agents. # In this case, we want to take the server's preferences. However, # let the clients decide since its not worth arguing over. # SSLHonorCipherOrder on
# Server Certificate: # Point SSLCertificateFile at a PEM encoded certificate. If # the certificate is encrypted, then you will be prompted for a # pass phrase. Note that a kill -HUP will prompt again. A new # certificate can be generated using the genkey(1) command. SSLCertificateFile /etc/ssl/private/cryptopp-com.cert.pem
# Server Private Key: # If the key is not combined with the certificate, use this # directive to point at the key file. Keep in mind that if # you've both a RSA and a DSA private key you can configure # both in parallel (to also allow the use of DSA ciphers, etc.) SSLCertificateKeyFile /etc/ssl/private/cryptopp-com.key.pem
# Server Certificate Chain: # Point SSLCertificateChainFile at a file containing the # concatenation of PEM encoded CA certificates which form the # certificate chain for the server certificate. Alternatively # the referenced file can be the same as SSLCertificateFile # when the CA certificates are directly appended to the server # certificate for convenience. SSLCertificateChainFile /etc/ssl/private/cryptopp-com.chain.pem
# Certificate Authority (CA): # Set the CA certificate verification path where to find CA # certificates for client authentication or alternatively one # huge file containing all of them (file must be PEM encoded) #SSLCACertificateFile /etc/ssl/...
# Client Authentication (Type): # Client certificate verification type and depth. Types are # none, optional, require and optional_no_ca. Depth is a # number which specifies how deeply to verify the certificate # issuer chain before deciding the certificate is not valid. #SSLVerifyClient require SSLVerifyClient none
# Add HSTS header. 7776000=3 Months; 15552000=6 Months; etc. # Header set Strict-Transport-Security "max-age=15552001; includeSubdomains;" </VirtualHost>
-
Chris Adams -
Francis.Montagnac＠inria.fr -
jarmo -
Jeffrey Walton -
Joe Zeff -
Markus Schönhaber -
Mike Wright -
Patrick O'Callaghan -
Peter Boy -
Samuel Sieb -
T.C. Hollingsworth -
Tim -
Todd Zullinger -
Tom Horsley