Does anyone know of a resource regarding how different ACME servers handle invalid replaces fields?
There isn't a unique error code, so it seems like I need to analyze the full error messages to figure out rejections based on this for an automatic retry.
EDIT: As I encounter them, I'll share the various codes:
Boulder
urn:ietf:params:acme:error:malformed
"parsing ARI CertID failed"
Pebble
urn:ietf:params:acme:error:serverInternal
"could not find an order for the given certificate: could not find order resulting in the given certificate serial number"
It would indeed be extremely helpful for client authors if specific error codes would be defined for this. The draft unfortunately only defines alreadyReplaced, which covers only one of many problems. I decided to simply retry (by default) after every error except alreadyReplaced (that is likely something the user should be informed about), which doesn't feel right, but seems to be the only thing that works. (If you don't want to rely on having to keep track of error messages of servers that can change over time etc.)
I think me and @webprofusion 's clients simply drop ARI replaces field in the order upon retrying any time the error isn't specifically handled in our code, just in case.
Not a bad idea. Right now I'm retrying based on 1) replaces in the payload, and 2) a few strings in the error. I should just check for the generic malformed code instead, and retry like you.