Change:
# StateDirectory must be relative, and will be created under /var/lib by systemd lpath = "acme/${cert}"; apath = "/var/lib/${lpath}"; <del> spath = "/var/lib/acme/.lego"; </del> <ins> spath = "/var/lib/acme/.lego/${cert}"; </ins> fileMode = if data.allowKeysForGroup then "640" else "600"; globalOpts = [ "-d" data.domain "--email" data.email "--path" "." "--key-type" data.keyType ] ++ optionals (cfg.acceptTerms) [ "--accept-tos" ]

Discussion:
Describe the bug The change from 19.09 to 20.03 (or unstable) breaks a potentially common workflow for certificate renewal: In simp_le age, each folder was named after the "name" attribute and was self-contained. In lego, a single folder contains all the generated certificates based on the main domain name This leads to situations where previously valid certificates will become overriden silently by leg, for instance if two different certificates have the same "main domain" key: The first systemd job to run will have a valid certificate while the second one will get the other one.
This link explains that the option (--filename) that would permit to avoid the issue is deprecated. In case my issue isn’t clear enough, the second point of the linked issue is the same as this one, so it seems like without this --filename option it would become impossible to be backward compatible with simp_le. The solution may then be to raise (or at least warn) when we have more than one certificate with a given "domain" key.
ping
I'm not sure if I understood the issue correctly, but you should refer to certificates from , not . This should create two timers writing to and , right?
Thanks for your example I have trouble explaining it correctly :) It will create two timers yes, but the content of will contain only one "set of file", , which may or may not include depending on the timer that ran first. And this result will then be copied to both and , so xmpp may have missing if acme- was the first one to run. Is it clearer presented like this?
I solved it using: This fix is not upstream though.
This looks reasonable. could you file a PR? With this applied, will it re-request certificates entirely from scratch? IMHO, this is a regression that should also be fixed for 20.03.
It will, but as far as I saw it is already the case in the current state (although I wouldn’t bet on it, it’s the impression I had when upgrading and I don’t see in the code why it would be otherwise)
The problem appears when you try to create different certificates that have the same domain as a common name (CN). Lego will use the CN as a directory name internally in its directory.

In my case I need multiple for certificates for some common domain for the following use cases: I have in nginx both and rsa2048 certificates, where rsa2048 is a fallback for older clients I need a different certificate for xmpp/ejabberd with the same main domain but not all subdomains than my webserver certificate. Additionally this certificate needs different filesystem permissions from my webserver one.
Can we get rid of it somehow?
these are lego-internal details - you shouldn't need to ever access them from there manually. The script is taking care to copy them to the appropriate locations, with the right permissions. These are all valid usecases for multiple certificates for the same domain, and I see this as a regression from 19.09. I just think if we should apply something like to nixpkgs, and get it backported to 20.03, so we avoid having another round of ssl certificate re-requests, as lego will re-request certs another time, due to the internally-changed paths.
I must have misunderstood the issue, then. So certificates are still under where name is the attribute name of the configuration but having multiple certificates with the same CN results in one overwriting another?
Certificates are exposed in (with being the name of the attrset, not the main domain). The certificate handling in the internal folder is messed up, which caused certs to be overridden in there (and then copied out) IIRC.
Ok, thank you. I get it now.
can you prepare a PR for master?
This issue has been mentioned on NixOS Discourse. There might be relevant details there: