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.