When renewing a certificate using win-acme, I got this error message from letsencrypt: "identifiers in this order do not match any identifiers in the certificate being replaced". It was very confusing, because in the CSR the domain matches the domain of the web site and the certificate being renewed. It turns out there likely was a mixup with the certificate of a sub domain. But from the error message you would be none the wiser (I actually completely forgot about the existence of the sub domain).
The request is to provide more information surrounding the received/expected identifiers in the error message so we don't have to post on forums to find out what's wrong.
As it turned out, the cause of the problem was likely a client problem (win-acme). But an improved letsencrypt error message would have directly exposed the issue as a likely client issue.
I've also requested improved logging from win-acme/simple-acme, but I think better error message from letsencrypt would be fantastic, so if a client misbehaves we will have a quicker understanding.
It's definitely a bit suboptimal that some error messages (like this one you mention, or bad JWT, or like CSR signed with SHA-1) are really targeted at client authors and the server administrator can't really do anything about it (other than checking for a newer client version maybe), whereas other error messages (like saying that your firewall is blocking the authentications) are really only helpful to the server administrator. And it may not be obvious which is which to many people. Clients could probably do a little more based on the urn:ietf:params:acme:error: code to give a hint as to whether it's something the user can do something about or not, though.
I checked the Boulder source after the last comment in the other thread. I also think it's a deficiency - the other conditionals here convey the context of an ARI identifier or replaces. Unless one knows this error code, this could reference any identifier. I'll create a ticket/PR
What jumped out to me on this situation, is that a subscriber would interpret mismatched identifiers as the domains have somehow changed on the order - but not realize this is because an incorrect replaces ARI id was sent. I think simply calling out "replaces" or "ARI" in these messages would be enough to point people at the right underlying issue.
Since this is a detailed feature request, I've replied directly on the github issue. Let's move the whole conversation over there so it's not happening in two places at the same time. Thanks!