curious .conf problem

David27 nginx-forum at
Sat Jan 8 23:49:39 UTC 2022

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
>> are viewable by people who might notice exploits, even those unrelated
>> 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

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


This original redirect server blocks of this form:

server {
  # listen 80;
  # listen [::]:80;
  # listen [::]:443 ssl;
  # listen 443 ssl;
  return 301$request_uri;

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

server {
  listen 80;
  listen [::]:80;
  listen [::]:443 ssl;
  listen 443 ssl;
  return 301$request_uri;

/etc/letsencrypt/live/; # managed
by Certbot
/etc/letsencrypt/live/; # managed by

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:,293269,293298#msg-293298

More information about the nginx mailing list