Duplicated order id for the same set of domain names from different accounts

Client dev
1

Is it possible for the same order ID to be returned for the same set of domain names in this scenario?

  1. Account A requests an order ID for [*.example.com, example.com].
  2. Account B requests an order ID for [*.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.

2

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 ?

2 Likes
3

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.

6 Likes
4

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

2 Likes