Has there been a recent change in order/authorization reuse behavior for the Classic profile?

Help
1

Hi Let's Encrypt team,

We maintain an ACME client that has been working reliably for 5+ years, but recently we've noticed unexpected behavior changes regarding order and authorization reuse. We're using the Classic profile (not EAB).

Previous Behavior (worked for 5+ years)
When making multiple POST /acme/new-order requests for the same account and domain:

We would receive the same order URL in the response Location header
The same authorization URLs were returned in the order object
Fetching the authorization (GET /acme/authz/{id}) returned the same challenge tokens
This allowed our manual DNS workflow to function correctly
Current Behavior (recently changed)
When making multiple POST /acme/new-order requests for the same account and domain:

Order URL behavior is inconsistent:
Sometimes we receive the same order URL (order is reused)
Sometimes we receive different order URLs (new orders are created)
Authorization reuse is unpredictable:
Sometimes the authorization URLs point to the same authorization object (same challenge tokens)
Sometimes we get completely different authorization URLs with different challenge tokens
No clear pattern or timing
The behavior appears random and cannot be reliably predicted
Test Results
We've tested with both staging and production ACME directories:

Existing account (used for years):

Some domains: Same authorization objects/challenges across multiple new-order requests ✓
Other domains: Different authorization objects/challenges for each new-order request ✗
Brand new account:

All domains: Different authorization objects/challenges for each new-order request ✗
ACME Protocol Flow
Our current implementation:

POST /acme/new-order with identifiers → receive order URL and authorization URLs
GET /acme/authz/{id} → retrieve challenge details
User manually adds DNS TXT records
POST /acme/new-order again (same identifiers) → expecting same authorization
POST /acme/challenge/{id} → validate and finalize
Questions
Has there been a recent change in how Let's Encrypt handles authorization reuse for pending orders within the same profile (Classic)?

What is the documented ACME behavior for multiple new-order requests with identical identifiers from the same account?

Should the server return the same pending order?
Should authorizations be reused across different orders?
Is this specified in RFC 8555 or is it implementation-specific?
Is authorization reuse timing-based?

Is there a cache/reuse window for pending authorizations?
What is the expected duration?
Is this behavior account-specific?

Why do older accounts show more authorization reuse than new accounts?
Is there an account age or history factor?
Environment
ACME Profile: Classic (not EAB)
ACME Directory: Both Staging (acme-staging-v02.api.letsencrypt.org) and Production (acme-v02.api.letsencrypt.org)
Protocol: ACME v2 (RFC 8555)
Testing Period: Issue noticed in recent weeks/months
We understand that proper ACME implementation should store and reuse the order URL from the initial new-order response, and we're working on that fix. However, we'd like to understand if there was an intentional behavior change in authorization reuse or if this is expected behavior we should have been handling all along.

Thank you for any clarification you can provide!

2

There is no documented behavior in the spec for this. Section 7.4 is where it would probably be if it did exist. But the only client guidance in there around orders and authorizations is:

Clients MUST NOT make any assumptions about the sort order of "identifiers" or authorizations" elements in the returned order object.

It was a mistake to rely on the order/auth re-use logic that the Boulder implementation happens to use. Semantically, it also makes sense that calling the newOrder endpoint again would result in...a new order (and associated new authorizations). It would need a field such as onlyReturnExisting like the newAccount endpoint to override that implicit assumption.

3

Ok, tnx... but do you know about a change that happened lately that may cause it?

4

I assume you are talking about Crypt::LE ? I worked on a thread with this problem recently (here).

I didn't see any documented changes to Boulder that would affect that.

There wasn't enough detail in the Crypt logs to see the responses from Boulder. If you can change the logs to provide that you might try posting on the github for Boulder. There may have been changes with, um, unexpected side effects. Those kinds of problems are a bit beyond what we could address in the community.

If you post more detailed logs we could review to ensure it looks like a bug / problem related to LE rather than your client.

That said, I agree with @rmbolger that counting on such undocumented behavior leaves you vulnerable. Even if LE discovers a recent change with the results you describe they may not consider it a breaking change worthy of a fix. I am just a volunteer here so can't speak officially.