Let's Encrypt API is randomizing the order of challenges and challenge combinations


To help the long-term stability of the ACME ecosystem, the order of the challenges and challenge combinations in the responses to new-authorization requests will be randomized. This change is currently in staging and will be in production on Sunday.

This shuffling in the new-authorization response is to ensure that ACME clients iterate through the challenges and combinations arrays instead of depending on the particular order that the Let’s Encrypt’s ACME API returned previously. That’s beneficial to clients because as the ACME specification and Let’s Encrypt evolves, challenges and combinations will be added and removed, and those changes, in turn, will cause clients depending on specific orders to fail. We believe it’s better to make any failures from order dependence occur now before we all have too much of an install base to fix them easily.

As you’re checking in on your clients for this case, also check to make sure that your client isn’t assuming that only one challenge will occur in a combination. Future ACME API implementations (from Let’s Encrypt or not) will likely require some certificates to have all possible challenge combinations have more than one challenge in them. In that case, clients not checking for the length of the combination array they’ve selected from the combination list before issuing challenges would not be able to receive the certificates.

But, that’s all advice for making robust clients that work against other and possibly future implementations of the ACME API.

Today, the Let’s Encrypt ACME API is simply randomizing the order of challenges and challenge combinations in new-authorization responses.

The commit that produced this change can be found at:


Also, sorry for the relatively quick turnaround here. Our deploy schedule was accelerated by some DNS timeout bug mitigations we wanted to put out there.