A constant cause of annoyance for me is the nebulous relationship between an Acme Order and Authorization in the RFC.
I've gotten some help on this concept here in the past, but trying to be server-neutral is requiring me to write a lot of extraneous code to handle edge cases of an Authorization being tied to multiple Orders, or vice-versa. At this point the workload to support this is too much and I realistically have to target support to the Boulder implementation.
I am hoping for some guidance on how Boulder handles the relationship between the two objects.
I generally do not care about an Acme Order re-using a validated Authorization, as that happens entirely within Boulder and the client is oblivious to it.
My concern is with Pending Authorizations and Orders. Can a pending Authorization be tied to more than one order in Boulder? Testing against Boulder and Pebble, a single Account can:
- generate a given Acme Order
- not trigger any validation
- generate a second, identical, Acme Order
- the authorizations of both orders will be different
Is this expected? Is this likely to change?
The concern for this, from a client developer perspective:
An ACME Challenge failure is fatal to an Authorization; an Authorization failure is fatal to an Order. Extra work is required to handle potential multiple Orders.
A lot of extra work is required to handle generating audit logs that correlate an Authorization a preferred Challenge (e.g. favoring DNS-01 to HTTP-01). As my "challenge preference" is tied to an ACME order, I have to work backward from a Challenge all the way to (multiple potential orders) to generate the right reporting - or generate a lot more logging data.
If Boulder isn't generating unique Pending Authorizations per Order, that is annoying and I'll have to handle this. If Boulder is generating unique pending auths, then there isn't any reason to do the additional work at this point.