Maybe relevant: I have another certificate, where the alphabetically first domain in the list of the command for the new certificate is the main domain. Maybe this influences which certificate is updated as well.
This depends on the version of Certbot that you’re using. There were various possibilities, but the historical behaviors are considered bugs. If you upgrade to 0.8.1 and create a cert from scratch (not updating an existing cert on your system), it should follow the exact domain order that you provide on the command line.
renew cert for domainA automatically (because it expires and the renew file is there)
cert for domainB domainA is about to expire, now it’s time to merge
run certbot -t -n certonly -d domainA -d domainB
the live/domainB cert is renewed (?)
run certbot without -t -n and get asked if it should be renewed hitting the 5 certs / 7 days limit (okay), but with the config domainB.conf (old cert which contains domainB domainA)
accept. The new certificate is stored in live/domainB again instead of live/domainA.
Moving the domainB.conf renewal file and editing all paths in it seems to help. But there is no main domain defined, so is the main domain chosen from the old cert or from the filename of the config file?
For automation i would like to have some command, which exactly creates a certificate with CN of the first -d argument and the alt-names in the order of the next domains (not that important).
But especially with a predictable filename. This means if a certificate is created, it should be in live/firstDomainname/cert.crt, no matter which certificate was extended/renewed with the command.