What are ACME Accounts?

In the Automated Certificate Management Environment (ACME) protocol (RFC 8555), an account represents a client's identity and registration with a Certificate Authority (CA). ACME accounts don't rely on credentials like usernames or passwords; instead, all interactions and authorizations are authenticated using public-key cryptography.

How are ACME Accounts registered?

To create an account, an ACME client generates an asymmetric key pair known as the account key. When registering with the CA (using the newAccount endpoint), the client provides the public key in JSON Web Key (JWK) format. The CA associates this key with the newly created account and assigns a unique account URL (account URI).

All subsequent requests—such as placing certificate orders or requesting revocations—must be cryptographically signed with the ACME account private key using JSON Web Signatures (JWS). The CA verifies these signatures using the registered public key.

What is tied to an ACME account?

In ACME, key aspects of domain validation and certificate lifecycle management are bound directly to the account:

  • Domain authorizations: All domain authorizations are tied to the ACME account. When a client successfully validates domain control (for example, using http-01 or dns-01), the CA issues an authorization associated with that specific account. If you request multiple certificates for the same domain name within a short interval, you may not need to re-prove domain control because the CA reuses the valid cached authorization tied to the account (Google Trust Services caches domain authorizations for up to 8 days). Because authorizations are account-specific, they cannot be shared across different ACME accounts.
  • Certificate revocation: The holder of an ACME account private key can revoke all certificates issued to that account (RFC 8555 Section 7.6). If multiple clients or services share an account, the account key holder has the authority to revoke certificates issued for any of them.

Can an ACME account key be rotated?

Yes. An ACME account key can be rotated without creating a new account or changing the account URI. A client initiates key rollover by submitting a request to the CA's keyChange endpoint (RFC 8555 Section 7.3.5).

During key rollover, the client submits a request signed by both the existing account private key and the new private key to authorize the change. Once verified by the CA, the public key associated with the account is updated. Because the account URI remains unchanged, existing authorizations and configurations bound to the account (such as DNS-PERSIST-01 records) remain valid.

How many accounts should I use?

You may choose to use many accounts or a limited number of accounts depending on your architecture and operational needs:

  • Many accounts: Having separate accounts (e.g., per machine, host, or isolated service) limits the impact if an individual account key is lost or compromised, and can simplify decentralized deployments. However, cached domain authorizations are not shared across accounts, meaning each account must independently validate domain control.
  • Limited/centralized accounts: Using a single account or a small set of shared accounts simplifies tracking, coordination, and external account binding (EAB) configuration across an organization, while allowing subsequent certificate requests to reuse cached domain authorizations. However, the holder of that account key can revoke all certificates issued to the account.

While generating new accounts dynamically per host is common for ephemeral challenges (http-01, dns-01), challenge mechanisms that rely on persistent authorization require consistent account identity.

ACME Accounts and DNS-PERSIST-01

If you plan to use DNS-PERSIST-01 (draft-ietf-acme-dns-persist) for domain validation, the choice and management of your ACME account key requires special attention.

Unlike other challenge types (such as dns-01), which require publishing a new ephemeral validation code to DNS for every certificate request or renewal, DNS-PERSIST-01 establishes a persistent DNS TXT record (at _validation-persist.<domain>). This record acts as an enduring authorization that permits the CA to issue and renew certificates for the specified domain without modifying DNS on each renewal.

Crucially, this persistent authorization is directly bound to a specific ACME account (identified by its account URI in the DNS record). Because the account key is what authenticates that account, the key itself authorizes dns-persist validation:

  • Maintain the same ACME account: To continue issuing and renewing certificates using an existing DNS-PERSIST-01 authorization, your client must continue using the same ACME account (account URI). If you create a new account rather than rotating your key using keyChange, the persistent DNS record will not authorize the new account, and certificate renewals will fail until the DNS record is updated with the new account URI.
  • Protect the account key securely: Because the account key authorizes certificate issuance for any domain configured with a matching DNS-PERSIST-01 record, compromising the account private key allows an attacker to obtain certificates for those domains. You must safeguard the private key with strong access controls, secure storage (such as a key management service or encrypted vault), and restricted access permissions.

More Information

For more details on ACME accounts, request signing, and protocol specifics, refer to the ACME protocol overview on accounts and RFC 8555 Section 7.3. For guidance on protecting account keys and account security, see How should I protect my ACME account keys?.