Unique identifiers for authorization objects and challenges?

Client dev
1

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.

1 Like
2

Anyone?

In tests against pebble and boulder, I haven’t seen been able to map an Authorization to multiple Orders, but I can’t find anything that defines this as expected behavior.

3

In Pebble, if you run with PEBBLE_AUTHZREUSE=100 create an order, fulfill it, and create the same order again, both orders should point to the same authz resources (= same URLs).

Same story with Boulder, but no need for any env variables.

As for your questions, I think there's a serious risk of overfitting to Let's Encrypt (or even the Let's Encrypt of "today") by being clever, but it will bite you eventually. Better to treat to everything as opaque and ephemeral.

One simple example - I've been burned repeatedly by assuming URL structures at one fixed point in time, that then changed.

3 Likes
4

arggggh. I had PEBBLE_AUTHZREUSE=1 in the test environment.

I'm seriously over budget and past a deadline on a product deployment. right now we're provisioning via certbot and loading certs our certificate manager, instead of having the certificate manager handle the provisioning itself. supporting future/non-letsencrypt systems has to be on the backlog.

1 Like
5

and thank you so much, @_az !!!

1 Like
6

Sorry. I probably should have added a _PERCENTAGE to the end of that env variable. Too late now D:.

1 Like
7

Ah ha!

I had the server configured right. @_az pointed me to my actual problem with this comment:

my tests weren't looking for duplicates across successfully validated authorizations, they were looking for duplicates across pending authorizations.

1 Like
8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.