Nope, you cannot use –expand if you are using a wildcard helper (in my case --dns-linode)
The command that worked was
certbot certonly --dns-linode --dns-linode-credentials ~/somefolder/somefile.ini -d davidgerisch.com -d gerisch.me -d *.davidgerisch.com -d *.gerisch.me --cert-name davidgerisch.com
certbot –expand was no good because of –dns-linode. My only choice was certbot certonly.
But leaving off the original certificate name created a new certificate in a new location with -0001 tacked on to the name. No way do I want to have to wrangle the original certificate with it’s expiration date and this new certificate and it’s other expiration date. Besides, my web server is already configured for the original certificate. Reconfiguring the web server was less than ideal.
So the secret was to use the –cert-name option to specifically update the existing certificate.
2022-12-27 Update: if you go to add another domain (which happened to be this one) and you get the error “Certbot failed to authenticate some domains (authenticator: dns-linode). The Certificate Authority reported these problems:
Domain: newdomain.tld
Type: unauthorized
Detail: No TXT record found at _acme-challenge.newdomain.tld
Domain: firstdomain.tld
Type: unauthorized
Detail: No TXT record found at _acme-challenge.firstdomain.tld
Hint: The Certificate Authority failed to verify the DNS TXT records created by –dns-linode. Ensure the above domains are hosted by this DNS provider, or try increasing –dns-linode-propagation-seconds (currently 120 seconds).”
The problem may actually be a leftover file at /etc/letsencrypt/renewal
I had two files in there: firstdomain.tld.conf and firstdomain.tld-0001.conf
Certbot was trying to use the -0001.conf file instead of the real file. The real file pointed to the actual certificates being served up. The -0001.conf file was pointing to certificates with -0001 in their name, which were never served up to any of my web sites.