Will Account rotation invalid the orders create by the old key?

Issuance Tech
1

We manage numerous external certificates, and customers are responsible for preparing the proof of ownership, which is beyond our control. However, we need to periodically rotate the account key. My question is: what will happen to active orders created with the old key once the account key is rotated? Thank you.

1 Like
2

I'm confused...
How are your customers involved with your ACME account?

2 Likes
3

@rg305 , it is a platform company, we are using our ACME accounts to manage the certificates for customer.
Could you please clarify if rotating the account key would invalidate active orders created prior to the rotation?

4

I wouldn't know.
Someone [who knows] will answer your question.

3 Likes
5

AFAIK, ROTATING the key should not invalidate any active orders BUT those orders will need to use the new account key moving forward - I have not tested it, but the last time I looked at boulder's source I did not see anything that would do that. I looked again and that doesn't seem to affect any orders ( see boulder/wfe2/wfe.go at 3377102aa880f897a3ec40d9ff349cc50d040d67 · letsencrypt/boulder · GitHub ) If you mark the key as compromised/REVOKE t, however, that does affect the active orders.

We manage numerous external certificates, and customers are responsible for preparing the proof of ownership, which is beyond our control

This description, along with your question, suggests you might have an anti-pattern deployed in your system.

Your customers can CNAME a DNS-01 _acme-challenge record onto your systems in advance; they can also enable a redirect for the HTTP-01 challenge onto your system as well.

If strategies like that are used, you should be able to finalize all pending certificates before a rollover.

4 Likes
6

Thank you, @jvanasco.
First, we don't mark the key as compromised or revoke it.

Secondly, we haven't deployed an anti-pattern in our system: customers can preconfigure a CNAME on the DNS-01 _acme-challenge record to point to our systems. However, for HTTP-01 challenges, the standard process from Let's Encrypt involves:

  1. Creating a new order to obtain the web token, and
  2. The customer then enabling web server access for the token, which can introduce delays.

During this setup period, account rotation may be required—especially with ARI, where we need to initiate renewal within the renewal window.

1 Like
7

There's nothing in the ACME protocol that requires account key rotation, that's an optional feature to mitigate/prevent account key compromise. This also has nothing to do with ARI. Where do you get the requirement that you need to rotate from?

4 Likes
8

Your customer could preconfigure their acme-challenge directory to 301 redirect onto your servers; they would not need to enable the web-access token. However, this is a weird situation though and might be purely theoretical. Why are you generating a certificate/challenge for a domain that does not point to your systems? The only reason I can think of is having a fallback certificate or "warming up" your service ahead of time - proxying the acme-challenge directory is probably the easiest solution for that IMHO.

2 Likes
9

Yes, the webpage for the customer server will point to our server indirectly. I did not expose the details in the previous posts. I just want to mention there is no control for the customer, and even for a simple configuration, it may take time for the customer to accomplish it.
Thank you all, I think I got the answers.

1 Like