Change:
- `screen`'s module has been cleaned, and will now require you to set `programs.screen.enable` in order to populate `screenrc` and add the program to the environment. <ins> - `security.acme.defaults.server` now has a default value instead of `null`. This effectively uses the same server, the Let's Encrypt production server, but makes the default explicit, instead of relying on the Lego default. A side effect of this is that the directory in which account data is stored changes and the ACME module will request a new account and new certificates for all domains.  This may cause issues if you pin an `acccounturl` in a CAA DNS record.  To avoid this, you may set `security.acme.defaults.server = null` to keep the old hashes. </ins> - `security.pam.sshAgentAuth.enable` now requires `services.openssh.authorizedKeysFiles` to be non-empty, which is the case when `services.openssh.enable` is true. Previously, `pam_ssh_agent_auth` silently failed to work.

Discussion:
After updating to 24.05, it appears that the ACME client (with the default infrastructure: etc.) registers a new account for obtaining letsencrypt certificates. If you had CAA with account binding enabled on your domains, the certificate renewals will now fail. If you are affected by the problem, here is how you can figure out the new account URI in order to update your CAA entries: -l and take the most recent directory This should probably be to the release notes.
And you will, of course, very rapidly hit the ultra-frustrating letsencrypt rate limits again. They really ought to revise those policies as it makes relatively minor bugs like this a much bigger pain in the ass than they should be..
cc
Did you update from 23.11?
Yes.
Suspect , because the two different directories I have now match the SHA256 of and . (Note the space at the start, which is the of the old default for the option.)
I honestly have no idea why this happened. The module hasn't had any significant changes for the past few years and nothing stands out in the recent history to me.
Wow good catch. Yes sounds like that is the issue
Do what's the plan forward? IMHO we should fix this whitespace and backport it to stable, assuming there's more people who didn't yet upgrade to the latest release vs that did. Also, there might be a chance people who already did the upgrade still have their old accounts available, no?
Apparently this bug was brought up during review: :(
Is this a solid assumption? With a maintainance window of just one month, there is quite some pressure to update NixOS. The issue is having to update the CAA records in the DNS, being able to still use the old account does not really matter.
Maybe we can keep the current method, but if the correct accounts directory doesn't exist, check if one exists under the old hash and move it? (EDIT: looks like server is part of the hash as well, my bad.)
What's really bad is neither got highlighted on the issue, nor did the release note update happen. This currently is a tire fire for everyone switching to it, either having them run into rate limits or having to update CAA records (after they notice, at all).
We could create a patch that migrates the directory like proposes.

Suggestion in the NixOS ACME/LetsEncrypt channel was similar. Something along the lines of: In any case we still should also add a note to the release notes as this migration doesn't help people who have already upgraded.
I've updated probably 25 VMs all with certs and didn't run into an problems and already forgot that this was a problem 4 months ago. I assume this is only a problem if you have the account ID in the caa record or if you have way to many http challenge certs with different accounts. We cannot just do that, as that would cause the opposite direction for anyone on unstable for the last 4 months, that already migrated or that recently installed 24.05. We probably need some state convergence.
Since landed the rate-limit issue is probably less of an issue in practise. I think we really only should care about breaking people's CAA setup. In that case I think we can get away with just an entry in the release notes and state convergence can be seen as a nice to have but not a must have.
At the Flying Circus, there's a high likelihood we're going to be affected by this nonetheless, despite the head-of-line registration blocker setup you mentioned, We have several hundred machines that'll request a new account when rolling out 24.05. When having to fix this downstream, I'd probably adopt a state convergence activation script approach. Alternatively, had proposed to re-allow as the account URL again, which would allow getting back the previous account hash string. If we adopt this here in NixOS upstream, that's a decent solution as well.
I'll work on a patch to re-allow null tonigh. Will post here for review in a bit!