Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot indicate an order replaces certificate with serial <code>, which already has a replacement order #560

Closed
stoimen-modeshift opened this issue Aug 8, 2024 · 4 comments
Assignees
Labels
bug Something isn't working

Comments

@stoimen-modeshift
Copy link

For a long time we have had configured a pipeline to renew our certificates. After upgrading the module to version 4.24.0 we started getting the following error on Submit-Renewal:

While validating order as a replacement an error occurred :: cannot indicate an order replaces certificate with serial <code>, which already has a replacement order

We are using the Azure DNS plugin for the challenge. I tried calling Remove-PAOrder and Revoke-PAAuthorization before Submit-Renewal to try fix the error but it didn't work.

Currently we reverted to the previous version of the module (v4.23.1) and the renewal works with it. Please advice if we need to fix something on our side or if this is a bug in the latest version of the client.

@rmbolger rmbolger self-assigned this Aug 13, 2024
@rmbolger rmbolger added the bug Something isn't working label Aug 13, 2024
@rmbolger
Copy link
Owner

rmbolger commented Aug 13, 2024

Hi @stoimen-modeshift, thanks for reaching out. This is likely a logic bug in the new ARI support that was added in 4.24.0. It sounds like the module is trying to tell the ACME server that the new order is replacing a previous order. But the ACME server thinks the previous order has already been replaced.

Short term, you can either stay on 4.23 which doesn't have the ARI code and wait for a fix or you can re-upgrade to 4.24 and just temporarily disable the ARI support using Set-PAServer -DisableARI.

I'm really curious what sequence of events led to the previous order being replaced without the module knowing about it. Is there anything special about your configuration or renewal workflow? Multiple servers with cloned configs or anything like that?

To a certain extent, it doesn't really matter though. The module should recognize the error and re-try without the ARI replaces parameter.

@stoimen-modeshift
Copy link
Author

As I mentioned we are using automated pipeline to renew the certificates and each time the pipeline is run it is using a newly provisioned virtual machine (we are using azure devops agents). We copy the certificate files on it and start the renewal process. To make it work we use the -UseAltPluginEncryption parameter on Set-PAAccount or otherwise we could not have the renewal process working on another machine. In general our code looks like this:

$env:POSHACME_HOME = "\directory\to\certificates"

Import-Module Posh-ACME -Force

Set-PAServer LE_PROD

Set-PAAccount -ID $env:ACMEACCOUNT -UseAltPluginEncryption

Submit-Renewal "domain1.com" -PluginArgs $pArgs -Force
Submit-Renewal "domain2.com" -PluginArgs $pArgs -Force
Submit-Renewal "domain3.com" -PluginArgs $pArgs -Force

I hope this helps.

@rmbolger rmbolger changed the title Issue with renewing certificates after upgrading to version v4.24.0 Cannot indicate an order replaces certificate with serial <code>, which already has a replacement order Aug 18, 2024
@rmbolger
Copy link
Owner

rmbolger commented Aug 18, 2024

I got some clarification from the ACME dev community and the ARI draft writers in issue #56. The draft should soon be updated with explicit guidance about how to handle this situation. But I've already added a fix based on their suggestions that should be live in the next version.

@rmbolger
Copy link
Owner

This fix is now live in 4.25.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants