Follow-up to #935.
RotateAcmeCredentials registers a replacement account and re-pins every ZT domain's CAA accounturi to it. The old ACME account remains valid at the CA.
Impact
CAA pinning only prevents the old account from issuing for our domains as long as the attacker cannot alter DNS. If the rotation motive is key compromise and the attacker also controls (or races) DNS, the old account can still complete issuance — and CAA resolver caching leaves a window even after re-pinning. Rotation as shipped is an operational re-pin, not a compromise-response tool; #935 documents this but does not close the gap.
Proposal
Deactivate the old account (RFC 8555 §7.3.6, "status": "deactivated") after the new credentials are published and CAA re-pinning succeeds:
- best-effort with a warning on failure, since the old credential may already be unusable (that is one reason to rotate);
- requires loading the old credential before overwriting it in KV, so the deactivation step must be sequenced into
do_rotate_acme_credentials;
- check what
instant-acme exposes for account deactivation.
Follow-up to #935.
RotateAcmeCredentialsregisters a replacement account and re-pins every ZT domain's CAAaccounturito it. The old ACME account remains valid at the CA.Impact
CAA pinning only prevents the old account from issuing for our domains as long as the attacker cannot alter DNS. If the rotation motive is key compromise and the attacker also controls (or races) DNS, the old account can still complete issuance — and CAA resolver caching leaves a window even after re-pinning. Rotation as shipped is an operational re-pin, not a compromise-response tool; #935 documents this but does not close the gap.
Proposal
Deactivate the old account (RFC 8555 §7.3.6,
"status": "deactivated") after the new credentials are published and CAA re-pinning succeeds:do_rotate_acme_credentials;instant-acmeexposes for account deactivation.