Those who choose to use DNS-PERSIST-01 should fully commit to automation and create one LetsEncrypt account per FQDN (or at least per loadbalancer), using a UUID as username.
Those who choose to use DNS-PERSIST-01 should fully commit to automation and create one LetsEncrypt account per FQDN (or at least per loadbalancer), using a UUID as username.
There is no username in ACME besides the account URI, so the UUID you’re suggesting isn’t needed. The account uri themselves just have a number (db primary key).
If you’re worried about correlating between domains, then yes just make multiple accounts.
There is an email field in ACME account registration but we don’t persist that since we dropped sending expiry emails.
It’s still a valid point IMHO - why not just use the public key directly? It seems like the account URI just adds problems instead of resolving any.
It has these primary advantages:
1. It matches what the CAA accounturi field has
2. Its consistent across an account, making it easier to set up new domains without needing to make any API calls
3. It doesn’t pin a users key, so they can rotate it without needing to update DNS records - which this method assumes is nontrivial, otherwise you’d use the classic DNS validation method
Interesting.
I didn't realize the email field wasn't persisted. I assumed it could be used in some type of account recovery scenario.