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