I can’t find an answer that helps me proceed in the RFC, so while I’d love this to work with all ACME - I am most concerned with Boulder. Hoping someone where can help again!
My client is centralized process/server that functions as both a Certificate Manager and ACME client. As an ACME client, it can only have one active challenge per-domain. As a Certificate Manager, it can queue up multiple certificates with shared domains for processing. To reconcile these two concerns, an active Acme
Challenge can block new Acme
Orders from processing.
My problem concerns "what is an
To make things simple for now, I’m just handling the blocking via the
Order's status. This is somewhat fine, but creates bottleneck concerns as some orders can take longer to process than others.
I’d like to make this determination more granular, by tying blocking activity to the
Challenge or `Authorization.
The RFC states a
Challenge is created in
pending, transitions to
processing when triggered and is then either
invalid based on the result. Ok.
processing block, the others don’t.
Also great, the RFC states that a
Challenge transition will further transition the state of the
Authorization if it is deterministic (a challenge transitions to
invalid); and non-valid
Authorization will make an
invalid. However, an
Order will leave the Authorizations
This leaves me with a few edge cases that I can’t figure out:
- When an
invalid, what happens to the remnant
Authorization, if any exist? The RFC states on page 55:
When finalizing an authorization, the server MAY remove
challenges other than the one that was completed, and it may modify
the “expires” field. The server SHOULD NOT remove challenges with
- If a
deactivatedby the client (or
revoked), what happens to the component Challenges?
The RFC on page 29:
For pending authorizations, the challenges that the client can fulfill in order to prove possession of the identifier. For valid authorizations, the challenge that was validated. For invalid authorizations, the challenge that was attempted and failed.
The RFC doesn’t address the other potential states.
I’m trying to cobble together what-to-do based on Pebble/Boulder behaviors. It seems the setting to re-use valid authorizations keeps everything serverside - the client is never shown the Authorization/Challenge (at least on Pebble).
Challenge object does’t have an expiry timestamp itself, which implies to me it’s functional expiration is tied to the
Authorization, and that a
Challenge is not going to be reused across authorizations. (Though I thought the DNS auth reuses something). In any event, the RFC implies a
Challenge is forever
pending until triggered - which just seems wrong.
It looks like it will be safe to block on this combination:
Challenge["pending" or "processing"] + Authorization ["pending"] + Order ["pending"]
However, I’d like to clean up the database and figure out if Challenges can be associated with different orders and what do to with them (if anything) once an authorization is deactivated.
This is related to an earlier question I had (Unique identifiers for authorization objects and challenges?)