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.