You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let's Encrypt posted the following yesterday. Is acme-tiny already up-to-date for this change? I seem to see some polling code so I think we should be safe, but just to make sure!
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 1: 8 hours in Staging
March 6: 24 hours in Staging
March 10-13: a whole weekend in Staging
March 20: enabled permanently in Staging
Assuming the Staging rollout goes smoothly, then:
April 5: 8 hours in Prod
April 10: 24 hours in Prod
April 14-17: a whole weekend in Prod
April 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.
The text was updated successfully, but these errors were encountered:
I tested the current version out on LE's staging environment when it was enabled there, and found no problems with it - although I don't know if they actually forced polling (it might not have occurred).
Let's Encrypt posted the following yesterday. Is acme-tiny already up-to-date for this change? I seem to see some polling code so I think we should be safe, but just to make sure!
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 1: 8 hours in Staging
March 6: 24 hours in Staging
March 10-13: a whole weekend in Staging
March 20: enabled permanently in Staging
Assuming the Staging rollout goes smoothly, then:
April 5: 8 hours in Prod
April 10: 24 hours in Prod
April 14-17: a whole weekend in Prod
April 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.
The text was updated successfully, but these errors were encountered: