How should I protect my ACME account keys?

In the Automated Certificate Management Environment (ACME) protocol (RFC 8555), an account key authenticates all interactions between a subscriber and the Certificate Authority (CA). The account private key serves as the cryptographic identity of the account.

Securing the ACME account private key is critical. While the compromise of an individual TLS certificate's private key affects only that certificate and the identifiers it contains, compromising an ACME account private key grants an attacker broad authority over your domain authorizations, certificate issuance, and certificate lifecycle management.

Why must ACME account keys be protected?

An attacker who gains access to an ACME account private key can perform several damaging actions:

  • Issue certificates using cached domain authorizations: When a client validates domain control (for example, using http-01 or dns-01), the CA issues an authorization tied directly to that ACME account. In Google Trust Services, domain authorizations are cached and reusable for a limited period. Within this window, an attacker with the account key can request and obtain valid TLS certificates for any of those domains without solving new challenges or having access to your DNS or web infrastructure.
  • Issue certificates under persistent authorizations (dns-persist-01): When using dns-persist-01 (draft-ietf-acme-dns-persist), domain validation is bound to the ACME account URI configured in the domain's DNS TXT record. Anyone holding the account private key can order and renew certificates for that domain, without needing further DNS access, until the DNS record is removed or updated.
  • Revoke active certificates (Denial of Service): Under RFC 8555 Section 7.6, the holder of an ACME account private key has the authority to revoke any certificate issued to that account. An attacker can revoke all active certificates issued by the account, triggering validation failures for clients and causing immediate service outages across production environments.
  • Modify account metadata or execute unauthorized key rollovers: An attacker holding the account key can alter contact email addresses, initiate account key changes using keyChange, or deactivate the account, stopping automated renewal pipelines.

Best practices for protecting ACME account keys

To safeguard ACME account keys effectively, adopt the following operational practices:

  • Secure storage and restricted permissions:

    • Where supported by your ACME client and environment, store account private keys in dedicated secret management systems (such as Google Cloud Secret Manager or HashiCorp Vault), Key Management Services / KMS (such as Google Cloud KMS), or a hardware solution like a Hardware Security Module (HSM).
    • If you can only save your account keys on disk, set strict file system permissions (such as 0600 or 0400) on the private key file so that only the dedicated ACME client daemon user can read it.
    • Never commit account private keys to source control repositories or embed them in container images.
    • Other options to consider include, storing account keys only in memory or a tmpfs and not persisting the private key at all (discarding it after use). Note that this requires registering a new ACME account for future certificate renewals. This can be cumbersome if External Account Binding is required.

  • Account segregation and adverse impact minimization:

    • For large deployments, whenever possible, centralize certificate management and securely distribute certificates and keys from the central system rather than having each endpoint make individual ACME requests.
    • Avoid sharing a single ACME account across unrelated systems, distinct business units, or separate environments (such as development, staging, and production).
    • Using separate accounts per host, service, or cluster limits the impact if a key is compromised: a compromised key on one host cannot be used to revoke certificates or leverage cached authorizations belonging to other hosts.

  • Key rotation and hygiene:

    • Ensure you can rotate account keys using the ACME keyChange endpoint (RFC 8555 Section 7.3.5). if needed. Key rollover updates the public key with the CA while preserving the account URI, ensuring that existing authorizations and dns-persist-01 records remain valid. Basic cryptographic hygiene requires that key rotation not be a significant event.
    • If an account key is suspected of being compromised, rotate it immediately using keyChange. If the account itself is untrusted or cannot be rotated, deactivate the account, establish a new account, and update any bound DNS records (such as DNS-PERSIST-01) with the new account URI.

  • Monitoring and auditing:

    • Monitor Certificate Transparency (CT) logs for unexpected certificates issued for your domains.
    • Audit access to ACME client hosts and secret management stores holding account keys.

Post-Quantum Cryptography (PQC) transition

As the Web PKI begins transitioning to Post-Quantum Cryptography (PQC) to defend against future cryptographically relevant quantum computers (CRQCs), subscriber authentication must also evolve:

  • The quantum risk to classical account keys: Today's ACME account keys predominantly rely on classical asymmetric algorithms (such as RSA and ECDSA, including NIST P-256 or Ed25519). These algorithms are susceptible to being broken by quantum computers running Shor's algorithm. Protecting the ACME control plane requires transitioning account keys to quantum-resistant signature schemes alongside end-entity certificate keys.
  • Account rekeying and rollover: As CAs and the ACME protocol standardize support for quantum-safe signatures, users should expect to rekey their existing accounts using the ACME keyChange mechanism to use PQC-secure ciphers. This will allow accounts to adopt quantum-safe credentials without changing account URIs or disrupting existing domain configurations.
  • Transitioning to new accounts: In early rollout stages or where clients don't support in-place rekeying to new algorithm families, users should expect to register new ACME accounts generated with PQC key pairs and migrate their certificate automation accordingly.
  • Client readiness: ACME client software and automation libraries will need updates to support PQC algorithms in JSON Web Key (JWK) and JSON Web Signature (JWS) formats. Operators should verify that their ACME tooling is regularly updated and prepared to adopt quantum-safe ciphers as CAs announce support.

More Information