Identifiers in this order do not match any identifiers in the certificate being replaced

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: www.woutware.com

I ran this command: C:\software\LetsEncrypt\win-acme.v2.2.9.1701.x64.pluggable\wacs --source:csr --csrfile:C:\tmp\certificates\csr.txt --validation:ftp --username:xxx --password xxx --store pemfiles --pemfilespath:C:\tmp\certificates --webroot:ftps://www.xxxcom/xxx/wwwroot/ --accepttos --emailaddress:xxx@xxx.com

It produced this output: identifiers in this order do not match any identifiers in the certificate being replaced

My web server is (include version): IIS

The operating system my web server runs on is (include version): Windows (machine I run wacs from is Windows 10).

My hosting provider, if applicable, is: winhost

I can login to a root shell on my machine (yes or no, or I don't know): don't know, dont think is relevant.

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): home brew control panel

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): I'm using wacs, not certbot

I'm trying to renew my www.woutware.com certificate. Using certbot goes ok, but using wacs I'm getting an error back from letsencrypt, and I have no idea why.

I cannot stress enough how unhelpful the error message is. If it would report the expected "identifier", and the "identifier" in the CSR, then I would be able to find the cause of the problem. So my request is two-fold:

  1. what can I do to find out what is the problem? I believe the CSR is correct, as certbot processes it without problem with a valid certificate as a result. Somehow the path the win-acme client (wacs) takes is slightly different, and I'm getting this obscure error.

  2. please please improve the horrible error message that lets-encrypt returns so we can actually trouble shoot ourselves.

2

I'm pretty sure the error does NOT come from Let's Encrypt, but from WACS: Let's Encrypt does not have a clue about which certificate is going to be replaced. Only WACS would know that.

Not sure why you immediately would assume this error came from Let's Encrypt?

That said, I don't run Windows, so no clue how to help with WACS.

See below, I didn't account for the new ARI (draft) protocol.. That's on me.

1 Like
3

I see from your github post for win-acme the error was:

"type": "urn:ietf:params:acme:error:malformed",
"detail": "While validating order as a replacement an error occurred :: identifiers in this order do not match any identifiers in the certificate being replaced",
"status": 400

That is a message from the Let's Encrypt server. It means that win-acme used the "replaces" option when requesting the certificate but the new certificate had different domain names (identifiers) than the cert stated in the "replaces".

You could check the win-acme log to find more details of what cert it tried to replace. Generally this means something went wrong in the ACME Client (win-acme in this case)

If you don't get any reply at win-acme github you may want to switch to using simple-acme. The principal maintainer of win-acme forked win-acme and says this about simple-acme:

"Going forwards, this is the version that I will be supporting and working on. I don’t expect there to be further releases of win-acme, unless ZeroSSL chooses to continue developing that project separately for themselves."

The website for simple-acme is https://simple-acme.com/

3 Likes
4

Hmm, ARI?

I didn't account for ARI implementations (yet).. Looks like WACS v2.2.3 back in April 2023 implemented draft 1 and the most recent version 2.2.9.1 from May 2024 implements draft 3.. We're currently on draft 8 though..

Certbot was just an example, please provide the WACS version you're using instead.

3 Likes
5

@woutware One other thing ... I see you got a cert for svn.woutware.com in Feb which recently expired. Is win-acme still aware of that cert? Perhaps it mistakenly tried to "replace" that cert when getting a new www.woutware.com cert?

4 Likes
6

Yeah, the matching identifiers requirement has been in place since draft 02. This seems more like a bug in win-acme. Maybe somehow related to them using a specific CSR and win-acme then not selecting the correct "replaces" certificate ID. Not sure.

An ACME Client could (should?) retry without "replaces" to avoid failing a cert request. I don't know enough about win-acme to say how it handles that (but apparently not well). In any case they will need to switch to simple-acme if it is a bug in win-acme instead of caused by their CSR or some other workflow issue.

3 Likes
7

@MikeMcQ Aha, this sounds like they could be mixed up! But I don't know where the mixup happens though. The CSR is for www.woutware.com. Could it be the mixup happens at letsencrypt? There's nothing in my wacs call that points to svn.woutware.com.

I use the same wacs call for another website/domain, so it should work. And previously it did work (probably before I added a certificate to svn.woutware.com).

The reason I created a separate certificate for svn.woutware.com is that it runs on a different machine and different ip address. And the setup with 2 separate certificates was working for the past few months.

1 Like
8

The version you can see in the command line I posted: 2.2.9.1701.x64

9

No, a mixup like that at the LE server would cause a vast number of problems which we would be well aware of. The code in LE that checks the matching identifiers is not complex. The far more likely answer is that win-acme sets a wrong "replaces ID".

wacs makes an ARI call to LE for some certificate and uses that cert-ID in the "replaces". It isn't something set in your command. Looks like wacs does the ARI call for svn for some reason. Or maybe even something else - not sure.

That is even more pointing to the origin of the problem. I don't know how to debug win-acme. You'll probably have better luck switching to simple-acme and asking about it on their site. Perhaps simple-acme already fixed whatever problem that is.

3 Likes
10

Hi Mike,

From my side things are still pointing to letsencrypt though. Because the thing is: I created those 2 certificates for the 2 domains on 2 separate machines, so in theory it shouldn't be possible for wacs to even know about the other domain and mix them up.

Can you see in the letsencrypt logging on your side what the mixed up identifiers are?

Also I think it would be super beneficial if we would get the 2 identifiers in the log/error message so we're not in the dark about what is going on.

In the mean time I will migrate to simple-acme and try that as well. Thank you for the suggestion.

11

You'll probably have better luck switching to simple-acme and asking about it on their site. Perhaps simple-acme already fixed whatever problem that is.

I can confirm that migrating to simple-acme version 2.3.2.1981.win-x64 fixed the issue.

Still I find that the error message returned by letsencrypt could be improved and would help pin pointing the root cause of the issue faster. Technically I still don't quite know what the problem was, and that's a bit unsatisfactory.

3 Likes
12

Maybe. Better logging in the ACME Client would be even more helpful. A better LE message could only identify the cert used for "replaces" which did not have matching identifiers. But, the ACME Client already knows what that was since it set that value in the request to LE.

And, it only occurs with faulty ACME Client code so even if it was more descriptive it still requires debugging the ACME Client and looking at its own log :slight_smile:

simple-acme is a better choice anyway since it has ongoing support.

3 Likes
14

Oops, I somehow deleted my message.

I mean to say, it's still good to have a letsencrypt error message reiterating the provided identifier, because as a user in this scenario, from the logging + lets encrypt error message we can't tell whether the problem is with the client, or the server. So with an improved lets encrypt error message that helps excluding the server as a factor, and we can directly dig deeper on the client side.

Anyways, thank you for all your help.

15

A cert can have a large number of "identifiers" (domain names) in it. A msg listing all of them could get verbose. The "replaces ID" could be returned in the msg but the ACME Client already knows what that is.

I've written an ACME Client and know from experience that handling "replaces" properly takes great care. A careful reading of the ARI specs is needed too. The Client needs appropriate "state info" and logging to track what is needed. In some cases retrying the cert request without "replaces" is necessary. Problems in this area are not something the operator of an ACME Client is likely able to fix on their own.

I think we pointed at the ACME Client as the problem pretty quickly. And, you got a resolution just by upgrading to the latest supported version. Perhaps asking Wouter at simple-acme would give you the deeper explanation you seek.

That said, you could post in the Feature Request section of this forum about improving the error message. You should probably post at simple-acme (and even win-acme) to ask them to improve their logging too :slight_smile:

2 Likes
16

Very verbose is great, it would be non-redundant information. Better to have it than don't have it.

I'll shoot in a feature request then.

I did request the win-acme guy Wouter to improve the logging indeed, thank you for the suggestion :).

17

Who is now the simple-acme guy :slight_smile:

2 Likes
18

Right, I know! He has provided support before a year ago or so, he seems very dedicated. I even asked him to invoice me for the provided support back then.

I put in a feature request regarding the error message: Improve the "identifiers in this order do not match any identifiers in the certificate being replaced" error message.

1 Like
19

I agree. I'd appreciate if you pass along any info he provides about what bug was fixed by simple-acme. Might help us if we see that error with wacs again.

2 Likes
20

Wouldn't shock me if it was just that simple-acme may not have known about the old certificate and so didn't send the replaces header.

2 Likes