Invalid ARI `replaces` field - different behaviors across ACME Servers?

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"

4 Likes

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.)

5 Likes

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.

4 Likes

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.

2 Likes

Yeah I did originally check for specific messages but it was getting out of hand and not practical across multiple CAs.

4 Likes