This doesn’t relate to the spec, but does relate to boulder/letsencrypt’s implementation.
Our ACME application persists everything in a centralized datastore (it’s really a certificate provisioning app for nginx/openresty with a client built into it). I’ve just upgraded our ACME client to v2 and am redoing the model now (we’ve been renewing with acme v2 clients, then uploading the certs into this system for quite some time).
Is there a way to uniquely identify challenge and authorization objects in the LE implementation?
An Order Object has an “authorizations” array of URLs. Each Authorization URL looks like a good candidate for being a unique identifier for the authorization.
- Are these Authorization URLs unique to the active Order, or could a different Order (by the same Account/Client/etc) present the same Authorization URLs?
- Are these Authorization URLs temporal/recycled or are they infinite? i.e. once an authorization url is generated, is it placed into a blacklist to never be used again?
An Authorization Object has a “challenges” array of objects. Both the Challenge Object’s URL and Token look like good candidates for being a unique identifiers to the challenge .
- Are these Challenge URLs unique to the active Order/Authorization, or could a different Order (by the same Account/Client/etc) present the same Challenge URLs?
- Are these Challenge URLs temporal/recycled or are they infinite?
- Should the tokens be consulted instead?
I recall several years ago the API introduced recycling of the authorization and challenge objects, but I can’t find any documentation on these specifics of this - does this mean only the challenge tokens are the same, or the urls too?
I know this sounds like overkill, but our system is designed for deploying certs across brandable white-label websites across clusters of servers – so we need to push all this stuff into a centralized SQL system and run analytics and reports to figure out what is going wrong.