security.acme doesn't work nicely with acme-dns provider

[flokli]

Describe the bug

Disclaimer: This is probably more of a lego issue/inconsistency, but due to some opinionated choices in the ACME NixOS module system it makes it hard to use this provider in NixOS.

I switched a few services over to use the NixOS ACME system. I use acme-dns to answer to DNS-01 challenges. Lego docs: https://go-acme.github.io/lego/dns/acme-dns/.

lego is configured with ACME_DNS_API_BASE and ACME_DNS_STORAGE_PATH. The latter already points to a file path containing secrets, so ACME_DNS_STORAGE_PATH_FILE probably allows specifying a path to a file which contains a path, which contains the secrets :shrug: .

This means, I cannot use our credentialFiles machinery to expose the file with the secrets, as it only allows configuring credentialFiles.*_FILE variables.

We should probably check back with upstream. I feel like ACME_DNS_STORAGE_PATH should just be deprecated in favor of ACME_DNS_STORAGE_FILE (which then doesn't do any indirections).

It seems unlikely someone is using ACME_DNS_STORAGE_FILE with its current behaviour.

As an alternative, we could extend the module system to allow ACME_DNS_STORAGE_PATH the same way we allow *_FILE, but it feels like an ugly hack, and I'd prefer fixing this upstream.

I currently manually set systemd.services."mydomain.example".serviceConfig.LoadCredential and systemd.services."mydomain.example".environment.ACME_DNS_{STORAGE_PATH,API_BASE} to get that behaviour.

Let me know what you think, I might be up to sending a PR upstream.

Notify maintainers

@NixOS/acme

Add a :+1: reaction to issues you find important.

[m1cr0man]

Just commenting to say I have seen this and I agree it is a problem. I too would like to PR upstream if someone doesn't beat me to it (spoiler: I won't be quick :melting_face: ). Infact, I have a couple of ideas I want to try and PR upstream to simplify things on our end, so this might be a good motive to get into it.