What's the account key used for?

Issuance Policy
1

What is the account key used for internally? From what I can tell, once certs expire you have to make a new request and go through domain validation anyway. I'm wondering if I can just generate a new key pair for the account key each time I make a request for a cert?

For context, I'm trying to find a solution to get Letsencrypt certs where our account key and cert keys will be stored in AWS KMS. For the cert key, I think we can use a two step approach:
a) Use a throwaway key to generate a CSR and re-sign the CSR with a KMS key using this GitHub - g-a-d/aws-kms-sign-csr: Re-sign a CSR with a KMS asymmetric private key script
b) Generate a cert using an existing CSR.

The only issue we have is the account key. Since it is a long-term key, we have to store it in KMS but if we do that we can't pass it to the ACME client during the certificate generation since KMS wouldn't allow the private key to be exported. If we create a single use account key during each certificate generation (every 90 days) we can effectively throw that key away. Would this approach work?

2

To identify the user and their authorizations, also to sign the api calls to the acme endpoint. There are rate limits that use it:

  • You can create a maximum of 300 New Orders per account per 3 hours.
  • There is a Failed Validation limit of 5 failures per account, per hostname, per hour.
  • You can create a maximum of 10 Accounts per IP Address per 3 hours. You can create a maximum of 500 Accounts per IP Range within an IPv6 /48 per 3 hours.
  • You can have a maximum of 300 Pending Authorizations on your account.

You can, but authorizations are valid for 30 days and are linked to the account key. So, you can disavow all authorizations (don't revoke your certs) and keep the key on the filesystem. If you don't disavow the authorizations the account key can be used to issue certificates for the hostnames you have validated using it.

I don't actually know if acme clients will complain on renewal, not finding the account key that was used to issue the certificate in the first place. You might have to treat every renewal as a new issuance.

About rate limits, using new account keys will probably break the reasoning between these two:

  • The main limit is Certificates per Registered Domain (50 per week).
  • Renewals are treated specially: they don’t count against your Certificates per Registered Domain limit, but they are subject to a Duplicate Certificate limit of 5 per week.

(I don't know it the second limit applies per account or just per domain set -- probably the latter)

1 Like
3

Is storing the account key in AWS KMS necessary? I'm not sure what the purpose/features of AWS KMS is, but I can imagine it is also responsible for cert/key management for TLS endpoints.

I don't really see a use for the account key except for communication to the ACME API by the ACME client, so it isn't required to be stored in AWS KMS.

3 Likes
4

Agreed, inbound keys should be kept very private.
Outbound keys are of much less "risk".

2 Likes
5

Thanks for the responses.

Yes this is precisely what I wanted to understand. What is the risk from the compromise of this key?

1 Like
6
  1. revoke your certificate with acme key from that account
  2. if you didn't deactivate auth, ask cert without new challange by reusing that auth for 30 days
  3. see what you did on that account by asking order list (see rfc8555 section 7.1.2.1)
  4. re-key or deactivate account, so any request you do later with that account key will fail
5 Likes
7

The obvious side-effect is that the holder of that account key can revoke all certs obtained with it.
The less obvious is that the system that held the key has been compromised; And there are likely other files/things more important to be worried about.

3 Likes
9

This is a strange feature of ACME, revocation without access to the cert private key.

I guess it's akin to contacting the CA and making them revoke the certificate.

2 Likes
10

Everything you wrote above is possible, but is an anti-pattern. Sometimes anti-patterns are necessary due to system constraints - are you sure your system has constraints that require this?

i) Some device/application has the unencrypted Private Key handy to decrypt traffic - can that be leveraged to sign your CSR?

ii) You could extend a client to use AWS KMS api calls to sign the API requests - or make some feature requests. Most clients have a single "encrypt payload" routine that is shared by all requests. A Python client could probably monkeypatched to handle this in a few hours.

IMHO, storing the Certificate Keys in AWS KMS will never be a correct pattern. I don't understand the utility of storing a public/private key pairing there, if you can never retrieve the private key. Why not just throw away that key after loading it into your software/hardware? It will essentially be the same thing.

Storing an Account Key in AWS KMS is potentially interesting in the context of an ACME Client directly utilizing it – but a system compromise in either situation would have identical results: someone either has direct access to the key and can sign things themselves, or they have access to your system which can access the key for signing.

You could absolutely have system/organizational restraints that require this, but it seems like a lot of mindless and fruitless overengineering to me.

4 Likes
11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.