Certbot: Improve predictability of output certificate (use --cert-name instead of --expand)
short description
Currently it is mere "luck" which domain will be the "primary" domain for certbot. This will lead to situations, where the LE config file in /renewal/ as well as the certs in /archive/ and /live/ are named "c.tld(.conf|.pem)" when requesting a certificate for a site with the domain "a.tld" containing sub- or alias domains for "b.tld", "b.a.tld" or "c.tld".
We have numerous cases where the same single vhost gets config files and cert files named with one of the additional domains. In addition to that the publicly displayed primary domain of the cert is one of the additional ones. This happens on newly requesting certs, renewing them and just updating them when e.g. adding or removing alias domains. For instance today we cleaned up 8 stale LE configs and certs for the one primary vhost / site. Those were named "a.tld-0001", "a.tld-0002", "b.tld", "c.tld", "x.a.tld", and so on ... After deleting all of them and creating a brand new LE cert + configs the config and cert file is off again. Instead of the expected "a.tld.conf" and "/live/a.tld/..." + "/archive/a.tld/..." it's all based on the last additional domain from the certonly cmd.
correct behaviour
The primary domain should be the domain of the vhost site. All subdomains, aliases and such should only be added as additional domains. The config as well as the cert files should be named with the primary domain. Also deleting alias or subdomains should update the existing certificate config and file instead of creating new ones.
From the Docs:
Consider using --cert-name instead of --expand, as it gives more control over which certificate is modified and it lets you remove domains as well as adding them.environment
Server OS: centos
Server OS version: centos7
ISPConfig version: 3.2.2
Certbot: 1.11.0
proposed fix
There are two issues in the current code I stumbled upon refactoring the LE code to allow Mirror Server SSL to work:
-
The cerbot call lacks the
--cert-nameoption. Thus certbot tries to guess internally which domain to use as primary domain. This can easily be solved supplying the--cert-nameoption with the primary domain. -
The current code adds the last supplied domain name as the host for the mail address. Haven't checked out whether this has any impact on the certbot guessing, but still I do not think, that this is intended
/bin/letsencrypt certonly -n --text --agree-tos --expand --authenticator webroot --server https://acme-v02.api.letsencrypt.org/directory --rsa-key-size 4096 --email postmaster@test2.domain.tld --cert-name=test2.domain.tld --webroot-map '{"test.domain.tld":"/usr/local/ispconfig/interface/acme","test2.domain.tld":"/usr/local/ispconfig/interface/acme","test3.domain.tld":"/usr/local/ispconfig/interface/acme"}'
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Requesting a certificate for test.domain.tld and 2 more domains
Performing the following challenges:
http-01 challenge for test2.domain.tld
http-01 challenge for test3.domain.tld
Waiting for verification...
Cleaning up challenges
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/test2.domain.tld/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/test2.domain.tld/privkey.pem