On Sat, Jan 08, 2022 at 06:49:39PM -0500, David27 wrote:

Hi there,

> Hello Francis, thanks for the hints. It is working now.

Good to hear you have something that works for you :-)

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

And thank you for this; it is very hard for someone who is *not* new to
the application and the documentation, to know what a new person would
do and where they would look.

So you experience may help others, and may help the documentation improve.

> 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.

Yes, common browsers tend to be "friendly", and hide lots of things for
the typical reading session.

For testing and checking what the server is actually returning, a client
like "curl" is often morehelpful.

> 3. The nginx access log was not complaining, but the site was not coming up.

For future testing -- it might be useful to use a different access_log in
each server{} block; or maybe to add $server_name to the log_format, to
make it clearer which server{} (and location{}) the request was finally
handled in.

> 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.

nginx, for better or worse, tends to believe that the configuration it
was given is the configuration that it was intended to be given. It's
one of those "user-friendly; but picky about its friends" balances.

> However, there was a catch all at the bottom of the conf file.
> That too was copied ... hmm

I suspect you're referring to

server {
server_name _;
return 404;
}

That's not a catch-all. If you can point at any documentation that
caused you to think that "server_name _;" means "catch-all server",
that documentation should be corrected.

A possible catch-all could be "server_name ~.;"; but the "proper" one
is of the form "listen [ip:]port default_server;"

> 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.

That's possibly "browser" vs "curl" again. Although I think both will
assume a protocol; curl will only follow redirects if you tell it to,
so it is easier to see what exact steps are taken.

> 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.

Strictly: 80 is started as root, and 8000 otherwise. But usually you
will be starting as root.

https://nginx.org/r/listen:

Default: listen *:80 | *:8000;

> 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.

That seems like a curious thing to do.

Maybe certbot "knows" that wildcard certificates are somehow special,
and chooses not to try to create them automatically? It looks like you
would have preferred for certbot to say which server_name values it was
requesting certificate for, and which it was not? Or maybe the distinction
between "wildcard" names and fixed names could have been clearer?

> 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.

That's a possible useful feature for the certbot people to consider.

Cheers,

f
--
Francis Daly francis@daoine.org
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx