Let's Encrypt returns duplicate order from New-PAOrder when details match an existing pending/ready order

[thomasgusset]

If you create two orders for the same MainDomain with different names, Submit-OrderFinalize doesn't use the submitted order.
create two orders:

New-PAOrder -Name Server1 -CSRPath .\server1.csr
New-PAOrder -Name Server2 -CSRPath .\server2.csr

List the orders

Get-PAOrder -List
Server1         vpn.netsecco.ch ready   ec-256    {}       
Server2         vpn.netsecco.ch ready   ec-256    {}  

Finalize first order
Get-PAOrder -Name Server1 | Submit-OrderFinalize
List the orders again -> order for Server2 has been finalized

Server1         vpn.netsecco.ch ready   ec-256    {} 
Server2         vpn.netsecco.ch valid   ec-256    {}

try to finalize second order

Get-PAOrder -Name Server2 | Submit-OrderFinalize
Submit-OrderFinalize : Order 'Server2' status is 'valid'. It must be 'ready' to finalize. Unable to continue.

try again with Server1

Get-PAOrder -Name Server1 | Submit-OrderFinalize
Order's status ("valid") is not acceptable for finalization

[rmbolger]

Hey, @thomasgusset. I don't think the problem is that Submit-OrderFinalize is not accepting the order name. I think the root of the problem is that for some reason Let's Encrypt is sending back a duplicate copy of the first order during the second New-PAOrder call. So you effectively have two local copies of the same underlying ACME order. So finalization of one affects both, but the local status isn't updated unless you do a Get-PAOrder -Refresh. If the private keys associated with the two CSRs are different, it would also mean the second order's cert wouldn't match the key for Server2.

You can check if the orders are a duplicate by comparing the location field for each one.

Get-PAOrder -List | Select-Object Name,location

I'm guessing Boulder (LE's ACME server implementation) is trying to conserve resources by returning the first order's object during the second order's request since it hasn't been finalized yet and from the Boulder's perspective, the order details are identical.

I'm going to ask about this in the community forums to verify what's going on. But my local testing makes it look like you can work around the issue by finalizing the first order before creating the second order. In that case, I'm guessing the second order is seen by Boulder as a renewal (albeit very early) and a new order object is created for it.

[rmbolger]

Found official confirmation about the Boulder behavior in their ACME implementation details doc:

https://github.com/letsencrypt/boulder/blob/main/docs/acme-implementation_details.md#order

Boulder may return a previously created Order when a given Account submits a new Order that is identical to a previously submitted Order that is in the "pending" or "ready" state.

So the workaround I described where you fully process one order before starting the next order seems to be a requirement in this case.

[thomasgusset]

Hi @rmbolger
thanks for feedback.
Just to be sure: it is supported to have two orders for the same FQDN (in my case we have two redundant servers and the certificates will be managed on a central management server)?
An other questions is if two orders are identical if their public keys are different?

[rmbolger]

Yes, totally supported from a Posh-ACME perspective to have two different orders for the same set of identifiers as long as they have different Name property values. It's the primary use case I had when implementing order names in 4.7. You won't want to go much beyond 2-3 identical certs though because Let's Encrypt enforces a duplicate certificate rate limit of 5 per week.

The only issue in this case was that due to the way LE re-uses order objects, the two orders in Posh-ACME were actually the same order. To prevent that, you have to finalize/complete the first order before creating the second order.

P.S. Knowing this is now a potential issue, I'm probably going to try and add some code to have New-PAOrder detect when a duplicate order is returned and throw an error or warning.

[rmbolger]

The change that throws an error on a duplicate order is now live in 4.11.0