Is it possible for the same order ID to be returned for the same set of domain names in this scenario?
[*.example.com, example.com].[*.example.com, example.com].We’ve observed this behavior recently (over the past few weeks) in our client. We rotate requests between our two accounts.
this function goven it:
if order.RegistrationID != acctID {
wfe.sendError(response, logEvent, probs.NotFound(fmt.Sprintf("No order found for account ID %d", acctID)), nil)
return
}
while path has account/order struct but it order is asked to sa without accountid, so it shouldn't have duplicate and I think wrong account for order should error out with No order found for account ID X ?
By "ID", do you mean the Location URI returned in the headers of a new order request? Because order objects in ACME don't really have an ID value per se.
If so, at least for Let's Encrypt that shouldn't be possible based on how LE's Boulder implementation seems to work. While you can't rely on this being true forever, the format of account and order URIs are related. For instance on Staging right now
| Type | Format without base URL |
|---|---|
| Account | /acme/acct/XXXXXXX |
| Order | /acme/order/XXXXXXX/YYYYYYYYYYY |
So the Order URI seems to have a portion of the Account URI in it. In my test environment, I have two different accounts with URIs such as
/acme/acct/1111111
/acme/acct/2222222
And after creating a duplicate order in each of them, the order URIs looks like this:
/acme/order/1111111/25191781111
/acme/order/2222222/25191782222
If you're treating the last portion of the URI as some sort of unique Order ID value (instead of using the whole URI), that's probably a bad idea. They were relatively close in my own test, but not identical. But even if they were the identical, you can't treat the orders as identical if the rest of the URI doesn't match.
Most id in boulder are db autoincrement, so it would be unique globally (as there is only one order table, not order of account tables)
But other things run it their own way so don't rely on it
The known, intentional, Boulder behavior is to recycle the Order ID for the same domains if there is a duplicate request. The logic to test that scenario is:
The second order id will be a duplicate as long as the first order did not answer any challenges. If the first one fails a challenge, a new order id should be created; if the first one successfully answers a challenge, I think the ID is recycled until Finalize is invoked - but I forget the exact logic flow.
The situation doesn't seem like it should be possible given the code shared above, but I haven't seen a testcase on this scenario.
On the one hand, order IDs should never be assumed to be unique across accounts. We may change how order IDs are assigned in the future.
On the other hand, today order IDs are globally unique, and can never be shared across accounts. If you believe the same order ID has been given to two different accounts, that's a serious bug and I'd like to understand what happened so we can investigate, fix it, and likely declare a compliance incident.
However, I suspect that what has happened here is that these two orders which you believe came from different accounts actually came from the same account. Can you please provide full logs of both clients creating their orders?
Yes, as we investigated further in our logs, we find out that the same order id was issued for the same account.