diff --git a/nixos/doc/manual/release-notes/rl-2103.xml b/nixos/doc/manual/release-notes/rl-2103.xml index 38262b508994..4138f569c385 100644 --- a/nixos/doc/manual/release-notes/rl-2103.xml +++ b/nixos/doc/manual/release-notes/rl-2103.xml @@ -439,6 +439,15 @@ been dropped from upstream releases. + + + In the ACME module, the data used to build the hash for the account + directory has changed to accomodate new features to reduce account + rate limit issues. This will trigger new account creation on the first + rebuild following this update. No issues are expected to arise from this, + thanks to the new account creation handling. + + now always ensures home directory permissions to be 0700. diff --git a/nixos/modules/security/acme.xml b/nixos/modules/security/acme.xml index 517162d1a7bf..3e7c8edfdf75 100644 --- a/nixos/modules/security/acme.xml +++ b/nixos/modules/security/acme.xml @@ -162,6 +162,9 @@ services.httpd = { ."foo.example.com" = { webroot = "/var/lib/acme/.challenges"; email = "foo@example.com"; + # Ensure that the web server you use can read the generated certs + # Take a look at the group option for the web server you choose. + group = "nginx"; # Since we have a wildcard vhost to handle port 80, # we can generate certs for anything! # Just make sure your DNS resolves them. @@ -257,10 +260,11 @@ chmod 400 /var/lib/secrets/certs.secret Should you need to regenerate a particular certificate in a hurry, such as when a vulnerability is found in Let's Encrypt, there is now a convenient - mechanism for doing so. Running systemctl clean acme-example.com.service - will remove all certificate files for the given domain, allowing you to then - systemctl start acme-example.com.service to generate fresh - ones. + mechanism for doing so. Running + systemctl clean --what=state acme-example.com.service + will remove all certificate files and the account data for the given domain, + allowing you to then systemctl start acme-example.com.service + to generate fresh ones.