Why Are ACME Account Keys and Certificate Keys Treated Separately?
ACME account keys and certificate keys may use the same accepted algorithms, but they are not interchangeable. Plan account arrangements and certificate use on recreated frontends with that separation in mind.
When certificate work is automated, seeing multiple key names in a configuration can be confusing. In particular, because the same RSA or ECDSA options are accepted for both account keys and certificate keys, it can seem as though they could be used interchangeably. Let’s Encrypt sets a clear boundary: an account key cannot be reused as a certificate key. Keeping the ACME account key and certificate key separate makes it easier to discuss account arrangements, key storage contexts, and certificate use on web frontends that are recreated repeatedly.
At a glance
- Let’s Encrypt accepts the same RSA and ECDSA options for account keys and certificate keys, but an account key cannot be reused as a certificate key.
- In ACME, one account can be used for all authorizations and certificate issuances, or a separate account can be created per customer.
- Under Let’s Encrypt’s CP/CPS and Subscriber Agreement, the subscriber for a certificate is the party that holds the certificate private key.
- Repeatedly created frontends should first try to use the certificate and private key in durable storage. A new issuance should be requested only when no certificate is available or all existing certificates are expired.
The same algorithms do not mean the same use
Let’s Encrypt accepts RSA keys that are 2048, 3072, or 4096 bits in length for both account keys and certificate keys. It also accepts P-256 and P-384 ECDSA keys for both types of key.
Those shared algorithm options do not make the two types interchangeable. Let’s Encrypt specifically states that an account key cannot be reused as a certificate key. Your configuration or key inventory should therefore treat account keys and certificate keys as separate records.
A practical first check is simple: before changing anything involving keys, write down whether the change concerns an account key or a certificate key. Their use of the same key algorithm does not remove that distinction.
- RSA keys of 2048, 3072, and 4096 bits are accepted for both key types.
- P-256 and P-384 ECDSA keys are accepted for both key types.
- An account key cannot be reused as a certificate key.
Source: [1]
Two options for the account arrangement
In ACME, one account can be used for all authorizations and certificate issuances. The other option stated in the source is to create one account per customer. The existence of these two options makes it important to record the selected account arrangement clearly.
Let’s Encrypt gives an example in which some hosting providers may want to use one account per customer. The same example includes storing account keys in different contexts. Its purpose is to prevent a compromise of one account key from allowing issuance for all of their customers.
Example scenario: Suppose a service provider handles certificate issuances for several customers. It can choose one account for all authorizations and issuances. Alternatively, it can create a separate account for each customer. With a per-customer arrangement, storing account keys in different contexts can be an option intended to prevent one compromised account key from allowing issuance for every customer.
- One account can be used for all authorizations and certificate issuances.
- A separate account can be created for each customer.
- Some hosting providers may store account keys in different contexts to prevent one compromise from enabling issuance for all customers.
Source: [1]
The party holding the certificate private key
Let’s Encrypt’s CP/CPS and Subscriber Agreement state that the subscriber for a certificate is the party that holds the private key for that certificate. This provides a direct basis for keeping a clear record of the party holding each certificate private key.
You can reflect this information carefully in a key inventory. For every certificate, record which party holds its private key as a separate entry. That record should be considered alongside the rule that an account key must not be reused as a certificate key.
It is important to retain the boundary stated by the source: the subscriber definition is based on the party holding the private key for the certificate. In an inventory, recording that clear and observable fact—the party holding the private key—is more precise than relying on unclear labels.
- The subscriber for a certificate is the party holding its private key.
- Record the party holding the private key for every certificate.
- Keep that record separate from the account-key record.
Source: [1]
Use an existing certificate first on recreated frontends
A frontend can be understood as the web layer visitors connect to. In infrastructure that may repeatedly create new frontends for the same website, Let’s Encrypt says those frontends should first try to use a certificate and private key from durable storage.
The source gives two conditions for requesting a new issuance: no certificate is available, or all existing certificates are expired. This means that a recreation event by itself should not be treated as a reason to request a new certificate.
Example scenario: Suppose a frontend serving the same website is removed and recreated. The new frontend first checks durable storage for a certificate and private key and tries to use them. It requests a new issuance if no certificate is available or all existing certificates are expired. This flow does not change the rule that an account key cannot be reused as a certificate key.
- A recreated frontend should first try to use the certificate and private key in durable storage.
- A new issuance can be requested when no certificate is available.
- A new issuance can be requested when all existing certificates are expired.
Source: [1]
Set up a practical record and review process
To reduce confusion around keys, review your records under two headings: account keys and certificate keys. State clearly which heading applies to every record. Do not attempt to use an account key as a certificate key.
When work is carried out for multiple customers, record whether the arrangement uses one account or one account per customer. If one account per customer is used, also review whether account keys are stored in different contexts. The source presents this approach as an option intended to prevent a compromised account key from allowing issuance for all customers.
Finally, in infrastructure where frontends are recreated, check the use of certificates and private keys from durable storage. Keep the decision to request a new issuance within the threshold given by the source: no certificate is available, or all existing certificates are expired.
- Separate key records into account keys and certificate keys.
- Do not reuse an account key as a certificate key.
- Record whether the account arrangement is shared or per customer.
- Record the party holding the private key for each certificate.
- Verify that recreated frontends first try to use the certificate and private key from durable storage.
Source: [1]
Practical checklist
- List account keys and certificate keys in separate records.
- Do not reuse an account key as a certificate key.
- Record whether the account arrangement uses one account or one account per customer.
- If using one account per customer, review the storage contexts for account keys.
- Record the party holding the private key for every certificate.
- Verify that recreated frontends first try to use the certificate and private key in durable storage.
- Request a new issuance only when no certificate is available or all existing certificates are expired.
An ACME account key and a certificate key are not interchangeable, even though the same RSA and ECDSA options are accepted for both. ACME can use one account or one account per customer, and some providers may store account keys in different contexts to limit the effect of a compromise. For certificates, the subscriber is the party holding the private key. On repeatedly recreated frontends, first use the certificate and private key from durable storage; request a new issuance only when no certificate is available or all existing certificates are expired.
Frequently asked questions
Can an account key be used as a certificate key?
No. Although Let’s Encrypt accepts the same RSA and ECDSA options for both account keys and certificate keys, it states that an account key cannot be reused as a certificate key.
Can one ACME account be used for all certificate issuances?
Yes. In ACME, one account can be used for all authorizations and certificate issuances. Alternatively, a separate account can be created for each customer.
Should every newly created frontend request a new certificate?
No. A frontend should first try to use the certificate and private key from durable storage. A new issuance should be requested only when no certificate is available or all existing certificates are expired.
