curious .conf problem

[David27]

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

There were quite a few layers of stuff here to unwrap, but yes, at the
bottom this came down to certbot behavior.  certbot saw the wild card
subdomain and then did nothing.   Yeah, I wish the combination of listening
on 443 and doing nothing had printed a message.  Still, a more experienced
person would have recognized that certbot had not added any new
certificates.

I was not sure that the subdomain even mattered when making an SSL
certificate, so when I saw the .domain.com  (dot in the front)  I had
assumed that it would make a certificate for the domain that applied to all
subdomains.  I now gather that this not a reasonable expectation.  I gather
that each subdomain gets its own certificate.  As each subdomin gets its own
certificate, of course certbot could not do anything with the wild card sub
domain.  It would have been nice if it had complained.

Well as we are talking wish lists, I wish that nginx followed a generic
unification algorithm without ad hoc recovery rules.  I.e. if there was no
block that unified, that it had an error rather than then applying an ad hoc
rule.  But nginx is what it is.

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

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