nixos/modules/security/acme: Issuing multiple certificates fails due to wrong file permissions

[hansjoergschurr]

Describe the bug
I have acme configured to issue multiple certificates via DNS validation for two different users:

security.acme = {
  acceptTerms = true;
  email = "me@example.com";
  certs."example.com" = {
    user = "nginx";
    domain = "*.example.com";
    dnsProvider = "gandiv5";
    credentialsFile = "/var/lib/secrets/gandi-api-key";
    dnsPropagationCheck = true;
  };
  certs."example.org" = {
    user = "service2";
    domain = "example.org";
    dnsProvider = "gandiv5";
    credentialsFile = "/var/lib/secrets/gandi-api-key";
    dnsPropagationCheck = true;
   };
 };

(the configuration is lightly edited for privacy). Both domains are using the same API key. The user "service2" is a system user.

When switching to this configuration one oft the acme-....service units fails to run with the error:

systemd[1]: Starting Renew ACME Certificate for example.org...
xy0l3na1dvjv71vj3q72lypg96pz4h7n-acme-start[8606]: 2020/06/04 22:05:20 Could not load RSA private key from file accounts/acme-v02.api.letsencrypt.org/me@example.com/keys/me@example.com.key: open accounts/acme-v02.api.letsencrypt.org/me@example.com/keys/me@example.com.key: permission denied
xy0l3na1dvjv71vj3q72lypg96pz4h7n-acme-start[8606]: 2020/06/04 22:05:20 Could not load RSA private key from file accounts/acme-v02.api.letsencrypt.org/me@example.com/keys/me@example.com.key: open accounts/acme-v02.api.letsencrypt.org/me@example.com/keys/me@example.com.key: permission denied
systemd[1]: acme-example.org.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: acme-example.org.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Renew ACME Certificate for example.org.
warning: error(s) occurred while switching to the new configuration

Indeed the folder /var/lib/acme/.lego/accounts/ is owned by the user for the other unit (nginx in this example). It seems non-deterministic which unit fails.

To Reproduce
Steps to reproduce the behavior:

1. Add the configuration to configuration.nix
2. Setup the api key in /var/lib/secrets/gandi-api-key
3. Run nixos-rebuild switch

Expected behavior
Two services acme-example.com.service and acme-example.org.service are started and two certificates are issued. The certificates should be readable by the corresponding system user.

Notify maintainers
@aanderse @andrew-d @arianvp @flokli @m1cr0man

Metadata

 - system: `"x86_64-linux"`
 - host os: `Linux 5.4.42, NixOS, 20.03.2015.e7752db2fb6 (Markhor)`
 - multi-user?: `no`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.5`
 - channels(root): `"nixos-20.03.2015.e7752db2fb6"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:

[m1cr0man]

We're going to be fixing this very soon. The plan is to remove the user/group options for certificates, and create an acme user and group. You can then add the likes of your nginx and service2 users to the acme group and they will have certificate access.

This is open to criticism/discussion at the moment. Feel free to chime in, @NixOS/acme

[hansjoergschurr]

How would that affect the private keys? If I'm not mistaken those are also generated by the acme module and with this approach every service in the group could read each services keys.

While this is not a problem in my case (this is a small personal server without high security requirements), I suspect others might want to keep that separated.

[m1cr0man]

That's a great point! This is definitely something that we should address.

I guess an easy way to solve this is to only force an acme user, and allow any group to be used. It will require some testing but I believe Systemd user/group arguments are not dependent on each other such that the user doesn't need to be a member of the configured group.

This way no matter which cert service creates the account folder both will have access to it, and the certs can only be read by their respective group members, solving the problem you just explained.

[m1cr0man]

From discussions on IRC with @emilazy, we feel there's actually more cases where people would want the private key to be read by multiple services than not. Consider the case where you have 1 domain and multiple services (web server, email, etc), you would want all those services to have access to the key.

We can still solve for your case too by simply keeping the group option and defaulting it to the acme group. We would just recommend adding other service accounts to the acme group for most cases rather than using a service account's group.

[flokli]

@m1cr0man just as a thought, but instead of adding random users to the acme group, could we just use xattrs to grant read permissions on the necessary key material?

[m1cr0man]

@flokli I don't think it's worth going that far with the base module. Given how things are set up at the moment, I don't think many people would go much farther than adding user to acme group security wise. That said, you could easily add some setfacl commands to the postRun script if you wanted.

[flokli]

Alright, fine for me too - let's get this issue fixed first :-)

[hansjoergschurr]

Sounds like a reasonable solution.