ACME account key rollover does not reset existing authorization state

An ACME account is identified by an account key. Certificate orders and authorizations are created in that account context, and clients use the key to sign most requests. Rotating the account key therefore looks like a natural containment step after a suspected compromise. It is useful, but it does not erase every piece of state that an attacker may have created.

RFC 8555 defines account key rollover as a signed operation. The server verifies that the request is authorized by the old account key and associates the account with the new key. The specification also says that changing the account key does not invalidate pending orders or authorization transactions solely because the key changed. That behavior supports continuity, but it means a responder should inspect outstanding orders, authorizations, and issued certificates rather than stopping after the rollover.

External account binding adds another layer. Some CAs require a new account request to carry a binding between the ACME account key and a key identifier supplied by the CA. A stolen external account binding key can be used to create a new account that is not the same account being rotated. A rotation plan should cover both the account key and any external binding material.

The same distinction applies to account deactivation. RFC 8555 allows a client to deactivate an account and says the server should deactivate each authorization associated with it. That is stronger than key replacement, but it still needs an inventory of orders and certificates already issued. Deactivation is not a certificate revocation command.

A sound containment sequence starts with evidence:

1. Inventory the ACME accounts and the clients that hold their keys.
2. Identify the account URL, key thumbprint, external account binding key, and current client configuration.
3. Review recent orders, authorizations, challenge types, and certificate issuance.
4. Revoke or replace certificates that may have been obtained without authorization.
5. Roll the account key and update every client that uses it.
6. Deactivate accounts or authorizations that should no longer exist.
7. Confirm that the old key can no longer perform protected operations.

Automation can make the first step difficult. One account key may be shared by many hosts, and several clients may be able to request the same names. A key rollover that updates one client but leaves another holding the old key can create a split-brain configuration. The CA may still accept requests from the account, while the old client cannot renew.

The certificate authority's logs and the internal client logs should be compared. A successful rollover proves that the new key works. It does not prove that no attacker-held order remains. Check the actual account and authorization state, then test negative cases with the old credential.

ACME key management is part of certificate operations. Rotation helps only when it is tied to an inventory, an authorization review, and a verification that old material has lost access.

References

• RFC 8555: Automatic Certificate Management Environment
• RFC 8657: CAA account URI and ACME method binding