We intend to make all order finalization asynchronous in the near future. This means that requests to the finalize URL included in Order objects will return very quickly, with the Order in "status": "processing". Clients will then have to poll the Order's URL until it transitions to "status": "valid", at which point they will be able to fetch the issued certificate as usual.
This is a change from the current status quo, in which successful requests to finalize orders always return with the order in "status": "valid" and the certificate ready to download. We are making this change because such synchronous requests often take a long time due to external dependencies (CT logs for precertificate submissions and DNS for CAA rechecking) and sometimes fail simply due to client-side timeouts. We expect this change to increase our overall issuance success rate, especially when those external dependencies are experiencing slowness or outages.
This asynchronous flow has always been specified in RFC8555. Other ACME servers such as ZeroSSL and Google Trust Services already conduct finalization asynchronously. Therefore we do not expect this change to cause breakage with many clients.
However, due to the possibility of breakage, we intend to follow a "brownout"-style schedule for deploying this change:
- March 15: 24 hours in Staging
- March 17-20: a whole weekend in Staging
- March 27: enabled permanently in Staging
Assuming the Staging rollout goes smoothly, then:
- April 5: 8 hours in Prod
April 10: 24 hours in ProdApril 14-17: a whole weekend in ProdApril 24: enabled permanently in Prod
All of the above dates are subject to change; watch this post for updates. As always, if you run into issues with this change, please post the details of your situation in the #help section of this forum.
19 Likes
Due to issues with this week's Staging deploy, we are skipping the March 1 brownout in Staging. We plan to continue the rest of the rollout as scheduled.
7 Likes
We're moving today's brownout to Wednesday, March 8th:
- March 8: 24 hours in Staging
8 Likes
The brownouts for Staging are going to start another week later. I've updated the post; the first Staging brownout now will be 24 hours on 15 March.
5 Likes
This has been (quietly) enabled continuously in Staging for a week now. We have not seen any increase in errors, nor have we received any complaints or bug reports from clients issuing against Staging.
We intend to proceed with brownouts in Prod as originally scheduled, starting with 8 hours this Wednesday, April 5th.
10 Likes
We enabled this in production at 17:07 UTC today, about 45 minutes ago. We will disable it approximately 00:00 or 01:00 UTC tomorrow, in ~8 hours
7 Likes
This has been disabled early, as of 22:16 UTC today.
10 Likes
Our brownout yesterday was very successful, giving us lots of useful data on which clients do and do not support async finalization. Based on that data and the great conversations in this forum yesterday, we've decided to cancel the rest of the prod brownouts, and to indefinitely postpone enabling asynchronous finalization in prod.
This change is one that we'd still love to make someday, but we have multiple other public-facing changes that we'd like to make this year. Those other changes are higher priority, and so we'd rather focus our efforts on ensuring that those changes go well.
If you are a client author, please continue work to support asynchronous finalization. It's necessary to be compliant with RFC 8555, and to interoperate with ACME servers other than Let's Encrypt.
If you are a website operator, please update or change your ACME client to one that supports asynchronous finalization for the same reason as above.
We'll leave async finalization enabled in Staging for an extended period, to allow client authors and website operators to test and verify that their clients work with it.
Please keep an eye out for further announcements regarding the other changes we intend to make this year. Exciting times are ahead!
16 Likes