7:11 a.m.
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-...
Any thoughts on this would be welcome, but please review the above link
before replying.
poc
7:55 a.m.
Sat, 22 Apr 2023 13:11:45 +0100
Patrick O'Callaghan <pocallaghan(a)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
12:41 p.m.
On Sat, 2023-04-22 at 15:55 +0300, jarmo wrote:
Sat, 22 Apr 2023 13:11:45 +0100
Patrick O'Callaghan <pocallaghan(a)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
1 p.m.
New subject: [OT] was Re: Certbot error
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.
8:30 a.m.
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-...
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 ...
--
Regards
mks
12:42 p.m.
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-...
>
> 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
4:31 p.m.
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.
--
Regards
mks
4:40 p.m.
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
8:21 a.m.
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.
--
Regards
mks
9:01 a.m.
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
9:10 a.m.
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
9:27 a.m.
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.
9:33 a.m.
Once upon a time, Patrick O'Callaghan <pocallaghan(a)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. :)
--
Chris Adams <linux(a)cmadams.net>
12:47 p.m.
On Sun, 2023-04-23 at 09:33 -0500, Chris Adams wrote:
Once upon a time, Patrick O'Callaghan
<pocallaghan(a)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
12:06 p.m.
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).
--
NB: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the list.
The following system info data is generated fresh for each post:
uname -rsvp
Linux 6.2.8-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Mar 22 19:14:19
UTC 2023 x86_64
12:45 p.m.
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 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(a)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
2:04 p.m.
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/ and https://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(a)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.
2:05 p.m.
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
--
francis
2:07 p.m.
On 4/23/23, Patrick O'Callaghan <pocallaghan(a)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.
2:21 p.m.
On 4/23/23, T.C. Hollingsworth <tchollingsworth(a)gmail.com> wrote:
On 4/23/23, Patrick O'Callaghan <pocallaghan(a)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.
2:36 p.m.
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.
--
NB: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the list.
The following system info data is generated fresh for each post:
uname -rsvp
Linux 6.2.8-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Mar 22 19:14:19
UTC 2023 x86_64
4:50 p.m.
New subject: Certbot error - SOLVED (?)
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
4:56 p.m.
New subject: Certbot error - SOLVED (?)
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.
4:14 a.m.
New subject: Certbot error - SOLVED (?)
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
7:51 a.m.
New subject: Certbot error - SOLVED (?)
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.
--
uname -rsvp
Linux 3.10.0-1160.88.1.el7.x86_64 #1 SMP Tue Mar 7 15:41:52 UTC 2023 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
9:11 a.m.
New subject: Certbot error - SOLVED (?)
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
12:44 p.m.
New subject: Certbot error - SOLVED (?)
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.
4:21 p.m.
New subject: Certbot error - SOLVED (?)
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
11:27 a.m.
New subject: Certbot error - SOLVED (?)
On Mon, Apr 24, 2023 at 5:14 AM Patrick O'Callaghan
<pocallaghan(a)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-apac...
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
4:21 p.m.
New subject: Certbot error - SOLVED (?)
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-apac...
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
5:08 p.m.
New subject: Certbot error - SOLVED (?)
Once upon a time, Patrick O'Callaghan <pocallaghan(a)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).
--
Chris Adams <linux(a)cmadams.net>
5:29 p.m.
New subject: Certbot error - SOLVED (?)
On 4/23/23 15:08, Chris Adams wrote:
Once upon a time, Patrick O'Callaghan
<pocallaghan(a)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).
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
7 p.m.
New subject: Certbot error - SOLVED (?)
Once upon a time, Mike Wright <nobody(a)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 <linux(a)cmadams.net>
7:54 p.m.
New subject: Certbot error - SOLVED (?)
Chris Adams wrote:
Once upon a time, Mike Wright <nobody(a)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(a)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).
--
Todd
9:14 p.m.
New subject: Certbot error - SOLVED (?)
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.
--
uname -rsvp
Linux 3.10.0-1160.88.1.el7.x86_64 #1 SMP Tue Mar 7 15:41:52 UTC 2023 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
5:53 p.m.
New subject: Certbot error - SOLVED (?)
On Sun, Apr 23, 2023 at 5:51 PM Patrick O'Callaghan
<pocallaghan(a)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
Jeff
5:58 p.m.
New subject: Certbot error - SOLVED (?)
On Sun, Apr 23, 2023 at 6:53 PM Jeffrey Walton <noloader(a)gmail.com> wrote:
On Sun, Apr 23, 2023 at 5:51 PM Patrick O'Callaghan
<pocallaghan(a)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.
Jeff
6:38 p.m.
New subject: Certbot error - SOLVED (?)
On Sun, 2023-04-23 at 18:58 -0400, Jeffrey Walton wrote:
On Sun, Apr 23, 2023 at 6:53 PM Jeffrey Walton
<noloader(a)gmail.com>
wrote:
>
> On Sun, Apr 23, 2023 at 5:51 PM Patrick O'Callaghan
> <pocallaghan(a)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
2:19 p.m.
Tim:
> 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(a)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?
--
NB: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the list.
The following system info data is generated fresh for each post:
uname -rsvp
Linux 6.2.8-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Mar 22 19:14:19
UTC 2023 x86_64
> If you browse to http://bree.org.uk/ and https://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).
2:54 p.m.
On Sun, Apr 23, 2023 at 3:20 PM Tim via users
<users(a)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
9:56 a.m.
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-...
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).
--
NB: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the list.
The following system info data is generated fresh for each post:
uname -rsvp
Linux 6.2.8-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Mar 22 19:14:19
UTC 2023 x86_64
12:45 p.m.
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-...
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
4:17 p.m.
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.
--
NB: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the list.
The following system info data is generated fresh for each post:
uname -rsvp
Linux 6.2.8-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Mar 22 19:14:19
UTC 2023 x86_64
4:30 p.m.
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
4:34 p.m.
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.
4:32 p.m.
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.
5:11 p.m.
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.
--
NB: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the list.
The following system info data is generated fresh for each post:
uname -rsvp
Linux 6.2.8-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Mar 22 19:14:19
UTC 2023 x86_64
5:16 p.m.
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.
5:17 p.m.
On Sat, Apr 22, 2023 at 6:12 PM Tim via users
<users(a)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
12:04 a.m.
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.
--
uname -rsvp
Linux 3.10.0-1160.88.1.el7.x86_64 #1 SMP Tue Mar 7 15:41:52 UTC 2023 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
5:12 a.m.
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
11 a.m.
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-...
Any thoughts on this would be welcome, but please review the above link
before replying.
poc
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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
11:24 a.m.
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-...
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.
12:26 p.m.
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
--
Todd
1:10 p.m.
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
12:40 p.m.
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-...
>
> 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
11:27 a.m.
Am 22.04.2023 um 14:11 schrieb Patrick O'Callaghan
<pocallaghan(a)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(a)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(a)fedoraproject.org
Timezone: CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member
Fedora docs team contributor
Java developer and enthusiast
12:48 p.m.
On Sat, 2023-04-22 at 18:27 +0200, Peter Boy wrote:
> Am 22.04.2023 um 14:11 schrieb Patrick O'Callaghan
> <pocallaghan(a)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(a)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
1:35 p.m.
Am 22.04.2023 um 19:48 schrieb Patrick O'Callaghan
<pocallaghan(a)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(a)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(a)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(a)fedoraproject.org
Timezone: CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member
Fedora docs team contributor
Java developer and enthusiast
4:23 p.m.
On Sat, 2023-04-22 at 20:35 +0200, Peter Boy wrote:
> Am 22.04.2023 um 19:48 schrieb Patrick O'Callaghan
> <pocallaghan(a)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(a)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(a)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>
It's documented in https://httpd.apache.org/docs/2.4/mod/mod_md.html so
I may try it.
poc
2:51 p.m.
On 4/22/23, Patrick O'Callaghan <pocallaghan(a)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.
4:39 p.m.
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(a)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.
12:25 p.m.
On Sat, Apr 22, 2023 at 8:13 AM Patrick O'Callaghan
<pocallaghan(a)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-...
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(a)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(a)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>
389
days inactive
391
days old
63 comments
14 participants
participants (14)
-
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