curious .conf problem

[David27]

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.

Posted at Nginx Forum: https://forum.nginx.org/read.php?2,293269,293298#msg-293298

_______________________________________________
nginx mailing list
nginx at nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx