Welcome! Log In Create A New Profile

Advanced

Re: curious .conf problem

January 08, 2022 06:49PM
Hello Francis, thanks for the hints. It is working now.

>> 2) Gosh I am also hesitant to put
>> the entire sites .conf file in a public email list where for evermore they
>> are viewable by people who might notice exploits, even those unrelated to
>> the issue at hand.
>
>That is a valid concern; best is if you can include a complete-but-minimal
> config

I will endeavor to provide a description that a reader can follow here.

First, these things made it more difficult to test/debug:

1. I copied over another configuration file that was in use and "working", thinking that it must be correct, but it wasn't.

2. The browser navigation bar was prefixing www automatically the second time a host was typed when the first time it had the www and second time it didn't.

3. The nginx access log was not complaining, but the site was not coming up. This is because by the rules it picked another server block with a different name, and by some nginx logic that was OK. (Francis explained it picked the first server block when there is no server name match for the given port. However, there was a catch all at the bottom of the conf file. That too was copied ... hmm

4. when sites were accessed via the browser without stating an explicit protocol, and no https protocol was specified in a server block, they defaulted to http rather than defaulting to https, then redirected by the server block for port 80. Hence some of the redirections on the original config that I copied were actually untested.

My mistakes:

1. I assumed that the server block would apply independent of the port if there was no listen port attributed to it. That seemed to be implied by the config file I had copied.. Francis points out here that is not the case, rather if there is no listen attribute, the server block will apply only to port 80.

2. The proximate cause for all these problems: Certbot did not generate an SSL certificate for a server block with a 'dot' prefix name even when it was listening to 443. It didn't complain, it just didn't expand the certificate.

Solution:

This original redirect server blocks of this form:

server {
server_name .thomaswlynch.com;
# listen 80;
# listen [::]:80;
# listen [::]:443 ssl;
# listen 443 ssl;
return 301 https://thomas-walker-lynch.com$request_uri;
}

were modified to the form that follows, then certbot was run again:

server {
server_name thomaswlynch.com www.thomaswlynch.com;
listen 80;
listen [::]:80;
listen [::]:443 ssl;
listen 443 ssl;
return 301 https://thomas-walker-lynch.com$request_uri;

ssl_certificate /etc/letsencrypt/live/reasoningtechnology.com-0001/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/reasoningtechnology.com-0001/privkey.pem; # managed by Certbot
}

With the server names listed with explicit subdomains, instead of using a dot prefix, certbot expanded the certificate to contain them. It only makes sense that certbot can not issue a certificate against a wildcard subdomain, though it would have been nice had it issued a warning.
Subject Author Posted

curious .conf problem

David27 January 06, 2022 08:37AM

Re: curious .conf problem

Francis Daly January 06, 2022 06:02PM

Re: curious .conf problem

David27 January 07, 2022 01:46PM

Re: curious .conf problem

Francis Daly January 07, 2022 04:30PM

Re: curious .conf problem

David27 January 08, 2022 06:49PM

Re: curious .conf problem

Francis Daly January 10, 2022 07:30PM

Re: curious .conf problem

David27 January 11, 2022 09:49PM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 52
Record Number of Users: 6 on February 13, 2018
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready