Should clients expect ACME server may drop accounts?

while testing against pebble and changing pebble's state quite a lot, noticed most client include certbot/lego/etc errors out when remembers a account on that domain but server doesn't know about it (because pebble doesn't know about it) and only way to recover from it is delete account dir from client manually.
but not sure if this pebbles behavior is intended or just an unfortunate side effect pebble not save any state between runs.
it looks like it clients may expect and guarded from LE may drop all accounts (like data center hit meteor and need to start R4) or pebble should support loading persistent accounts.


Usually one prepares for meteors hitting datacenters...
I now have to rethink my meteor defense/redundancy contingency plans - LOL


And I'm adding this to my todo list for CertSage...



Should they expect it as part of a normal functioning CA during a reasonable lifetime of an account, probably not. But should the be capable of handing it if/when it happens, I would think so.

No online service is going to be capable of keeping an unlimited amount of user data forever. I would hope that any well designed CA has retention policies based on usage that would purge dormant accounts and data. Obviously unexpected data loss can always happen as well.

And beyond the CAs control, many environments share ACME accounts between servers. The account a client is relying on could have been manually deactivated by a client on another machine.


It is intended. Clients should assume a Server may drop the account or key at any point in the future.

Pebble originally used a serial number for the account ids/urls, which created an issue for some people across multiple tests (well, at least me and a few others), as it created issues where accounts were semi-persistent. The account might be different, but the URL would be reused. That was addressed in Randomize the account ID generated by squizzling · Pull Request #348 · letsencrypt/pebble · GitHub to offer fully random URLs so they can not persist across runs.

Historically, LetsEncrypt has blocklisted AccountKeys due to them appearing on "weak keys" lists - or on demand in the case of a compromised key. If clients did not expect the account or key were lost/blocked, they could not handle those situations properly.


I think it is possible that Let’s Encrypt may drop accounts in the future, and handling that case would be good. Realistically many clients don’t handle that so it would have to be a long phase-in, and we’d presumably only drop accounts that look unused so most clients wouldn’t hit this. (eg: no activity in 5 years, or never issued any certificates and is 1 year old, or some other scheme like that.)

One of the vague concerns I have is that it’s possible for a DDoS to spam account creation from many IPs which we then store forever. Ideally we don’t want to have to store anything forever or else our data is continually growing!


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.