i don't think this is the same issue as #56678. or at least what i'm seeing on my server is that the wrong certbot cmd line is generated, which then results in saving the challenge at the wrong path.
this is the mcron that gets generated: [...]/certbot certonly -n --agree-tos --webroot -w /srv/http/ --cert-name dwim.hu -d dwim.hu --email att...@lendvai.name and this what worked when i fixed the -w arg: [...]/certbot certonly -n --agree-tos --webroot -w /srv/http/dwim.hu --cert-name dwim.hu -d dwim.hu --email att...@lendvai.name i.e. the -w parameter should point to the webroot of the virtual domain, but the guix config structure does not allow setting the webroot for each <certificate-configuration>, only at their parent, i.e. in the <certbot-configuration>. this all seems to me as if the certbot service code was assuming that the certbot script will append the domain names (specified with -d) to the webroot path, but it does not. from the certbot log (i.e. challenge is saved at the wrong path): "Removing /srv/http/.well-known/acme-challenge/[hash]" the relevant code is from 2018, so certbot's behavior may very well have changed since then: https://git.savannah.gnu.org/cgit/guix.git/commit/gnu/services/certbot.scm?id=c3215d2f9d8fa4b890e3a41ceb4404b76a7c5c49 it seems to me that the webroot field should be moved down into <certificate-configuration>. am i right? if so i may try to patch this up. -- - attila PGP: 5D5F 45C7 DFCD 0A39 -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “State is the name of the coldest of all cold monsters. Coldly it lies; and this lie slips from its mouth: "I, the state, am the people."” — Friedrich Nietzsche (1844–1900), 'Thus Spoke Zarathustra' (1885), http://j.mp/1k6pbwS
