Support setting defaults for security.acme.certs

[catern]

Issue description

The ACME support in https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/security/acme.nix is nicely integrated with other modules; for example, services.httpd will automatically configure security.acme.certs based on the other configuration in services.httpd: https://github.com/NixOS/nixpkgs/blob/nixos-21.05/nixos/modules/services/web-servers/apache-httpd/default.nix#L672

However, if there's anything nonstandard about how certificates need to be acquired (for example, if one is using DNS-based authentication and needs to set security.acme.certs..{dnsProvider,credentialsFile}), this integration won't work and one is forced to do things more manually.

If we supported configuring defaults at the security.acme level (e.g. security.acme.{dnsProvider,credentialsFile}) the user could customize the process of acquiring certificates, while still getting automated integration with other services.

I'm not sure exactly what form this should take, hence why I'm filing this issue instead of just doing it and submitting a PR, but happy to do it if someone can give me a few pointers to other services that have this kind of defaulting structure.

[m1cr0man]

Yeah, this is quite an interesting idea. Setting "defaults" or common configuration in that way would simplify configuration (even if you could technically do this already with some commonCertConfig // { newValues } style attrset updating) and as you say makes it possible for auto config of other stuff.

I don't think it would be too much work to do either due to the way the module works. We already do this with security.acme.email & security.acme.certs.<cert>.email, so I don't see why not for the other things.

I'll put it on my to-do list for next time I do an update to the module, but if you want to try it yourself by all means have a go! Looking at the logic around secuirty.acme.email would definitely be a good starting point, and all you would likely need to do is duplicate it for the other options. iirc, all we do is set the default of the security.acme.certs.<cert>.email option to config.security.acme.email, so all you need to do is add the relevant new options + update the defaults for the cert-specific options.

[m1cr0man]

This turned out to be quite the handful to implement! Firstly, it took quite some discussion to figure out where best to place these two levels of defaults were. We settled on config.security.acme.defaults for the following reasons:

• Clarity of intention. If they simply sat at config.security.acme one might initially raise an eyebrow as to why all the .certs options are duplicated a layer below.
• Ease of overriding. I plan to add a config.security.acme.certs.${cert}.inheritDefaults option which will toggle whether these options are pulled for a given cert or not. If you want to bring in just a few of the defaults, you can combine this with { inherit (config.security.acme.defaults) valYouWant; } for specific defaults or a filterAttrs-style selection. You could also leave inheritDefaults alone and set the unwanted values to their true defaults.

Additionally, implementing the example you gave in this ticket of specifying dnsProvider defaults for httpd/nginx-generated certs was a bit tricky. webroot and dnsProvider are mutually exclusive so I had to add a way of setting vhost.acmeRoot to null which in turn would avoid overriding the webroot configured from the acme module. Docs will follow on how to set this up :)

[m1cr0man]

Resolved (and documented!) in #147784