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

**URL:** <https://community.letsencrypt.org/t/duplicated-order-id-for-the-same-set-of-domain-names-from-different-accounts/238288>\
**Category:** Client dev\
**Created:** [June 8, 2025, 6:34am UTC](https://community.letsencrypt.org/t/duplicated-order-id-for-the-same-set-of-domain-names-from-different-accounts/238288 "2025-06-08T06:34:34Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![mehrdadep](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mehrdadep/32/84381_2.png) [@mehrdadep](https://community.letsencrypt.org/u/mehrdadep)\
**Post date:** [June 8, 2025, 6:34am UTC](https://community.letsencrypt.org/t/duplicated-order-id-for-the-same-set-of-domain-names-from-different-accounts/238288/1 "2025-06-08T06:34:34Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![orangepizza](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/orangepizza/32/19597_2.png) [@orangepizza](https://community.letsencrypt.org/u/orangepizza)\
**Post date:** [June 8, 2025, 6:52am UTC](https://community.letsencrypt.org/t/duplicated-order-id-for-the-same-set-of-domain-names-from-different-accounts/238288/2 "2025-06-08T06:52:38Z")

</div>

this function goven it:

> <https://github.com/letsencrypt/boulder/blob/main/wfe2/wfe.go#L2429-L2435>

```nohighlight
	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` ?

---

<div class="post-metadata">

**Author:** ![rmbolger](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rmbolger/32/27474_2.png) [@rmbolger](https://community.letsencrypt.org/u/rmbolger)\
**Post date:** [June 8, 2025, 7:06am UTC](https://community.letsencrypt.org/t/duplicated-order-id-for-the-same-set-of-domain-names-from-different-accounts/238288/3 "2025-06-08T07:06:01Z")

</div>

By "ID", do you mean the Location URI returned in the headers of a new order request? Because [order objects](https://datatracker.ietf.org/doc/html/rfc8555/#section-7.1.3) 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.

---

<div class="post-metadata">

**Author:** ![orangepizza](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/orangepizza/32/19597_2.png) [@orangepizza](https://community.letsencrypt.org/u/orangepizza)\
**Post date:** [June 8, 2025, 7:19am UTC](https://community.letsencrypt.org/t/duplicated-order-id-for-the-same-set-of-domain-names-from-different-accounts/238288/4 "2025-06-08T07:19:04Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\
**Post date:** [June 9, 2025, 2:20pm UTC](https://community.letsencrypt.org/t/duplicated-order-id-for-the-same-set-of-domain-names-from-different-accounts/238288/5 "2025-06-09T14:20:18Z")

</div>

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:

- Submit Order for domains x, y , z; do not respond to challenges.
- Submit Duplicate Order for domains x, y, z.

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.

---

<div class="post-metadata">

**Author:** ![aarongable](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/aarongable/32/42043_2.png) [@aarongable](https://community.letsencrypt.org/u/aarongable)\
**Post date:** [June 9, 2025, 4:07pm UTC](https://community.letsencrypt.org/t/duplicated-order-id-for-the-same-set-of-domain-names-from-different-accounts/238288/6 "2025-06-09T16:07:13Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![mehrdadep](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mehrdadep/32/84381_2.png) [@mehrdadep](https://community.letsencrypt.org/u/mehrdadep)\
**Post date:** [June 10, 2025, 10:33am UTC](https://community.letsencrypt.org/t/duplicated-order-id-for-the-same-set-of-domain-names-from-different-accounts/238288/7 "2025-06-10T10:33:18Z")

</div>

Yes, as we investigated further in our logs, we find out that the same order id was issued for the same account.

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\
**Post date:** [July 10, 2025, 10:34am UTC](https://community.letsencrypt.org/t/duplicated-order-id-for-the-same-set-of-domain-names-from-different-accounts/238288/8 "2025-07-10T10:34:11Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
