"Order-xxxyyyzzz.key.xml already exists. This method will not override existing files" on renew

[c-amie]

"Order-xxxyyyzzz.key.xml already exists. This method will not override existing files" on renew

[glatzert]

Part of the filename is the Order Hash, which is constructed using the ResourceUrl (the URL which is associated with our order) and the identifiers. This means the order url is the same as in the last order and that probably means, ACME just passes you the already existing order. You might be able to verify that, by using -PassThru and -Verbose switches on the commands, but I'm not 100% positive it will yield the data.

Use Find-Order for the current order, that should show you the ResourceUrl, after that remove the key.xml and retry - if it yields the same ResourceUrl, the ACME server recovers the already exisiting order for you (probalby it's already valid)

Essentially the module does not cope well with pre-existing orders.
That's something, which should be fixed in the future, but probably is not very important, since it'll not happen very often in real-world-usage.

[c-amie]

Sorry for my slow reply, we live in busy times!

You are correct, $order | Update-ACMEOrder -State $state -PassThru -Verbose doesn't show anything else to debug with.

Are you saying that I am seeing this because I am attempting to renew the certificate before its expiration lifetime, at which time, if I do this, this error won't happen? You say that it won't happen very often in real-world use, which implies that I'm causing something artificially to happen here?

If I use this to clean-up the .key.xml:
if ($(Test-Path -LiteralPath "$ServiceDirectoryPath\Orders\Order-$($order.GetHashString()).key.xml")) {
Write-Host "Order-$($order.GetHashString()).key.xml Exists" -ForegroundColor Magenta
Write-Host "Cleaning-up..."
Remove-Item -Path "$ServiceDirectoryPath\Orders\Order-$($order.GetHashString()).key.xml" -Force
}

I now get:

Server returned Problem (Status: 404).´nNo order for ID ##########
At C:\Program Files\WindowsPowerShell\Modules\ACME-PS\1.1.5\ACME-PS.psm1:1401 char:13

•         throw [AcmeHttpException]::new($response.ErrorMessage, $r ...
  

•         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  

  • CategoryInfo : OperationStopped: (:) [], AcmeHttpException
  • FullyQualifiedErrorId : Server returned Problem (Status: 404).´nNo order for ID ########

[glatzert]

What I wanted to express was, that If you do something like:

New-AcmeOrder [...] and more or less directly afterwards repeat that for the same identifiers, Let's-Encrypt will probably return the SAME order object. BTW: I think the staging platform will NOT show that behaviour and always return a new order.

If you call New-AcmeOrder the response will contain a ResourceUrl, pointing to the order on the LE-server. This URL will be used for Update-Order and it'll be contained in the order-hash.

The latter one probably being the reason, that your code failed the first time and the first use case being probably the reason Update-AcmeOrder is failing now.

If you refresh your certificates after ~2/3 of their lifetime, everything should work fine (since I'm using the tool myself to manage ~50 sites, I'm relatively sure it works correctly ;))

[c-amie]

Hi glazert,

It isn't actually, I have only been using the staging platform so far I haven't hit the live one as I want to get the scripts correct before I do. This behaviour is coming from staging.

Interesting, thank-you. I will have to wait another 7 weeks or so and try it again. Is there a strategy to clean up the error message and indicate that the API shouldn't be re-cycled before 8 weeks rather than throwing the file violations.

Thanks for your project!

[glatzert]

Just to add something for clarity,

to renew a certificate you'll need to create a new order object and not reuse an old one (which you might retrieve via Find-ACMEOrder).

I'll keep this issue open as a reminder to look into handling of order objects, which get the same id as an already existing order.