Challenge response questions (ACME v2 / pebble)

[jvanasco]

I’ve got my client running on AcmeV2 finally - thank you all for the help so far!

I have one outstanding question which I can’t seem to figure out. I think this may be an artifact from testing against pebble and having some options set (or failing to reset the server), but I’d like to clarify.

After I create a new order, I loop through the authorization response (https://tools.ietf.org/html/rfc8555#section-7.1.4) for challenges.

Using the example challenge from the RFC…

   {
     "url": "https://example.com/acme/chall/prV_B7yEyA4",
     "type": "http-01",
     "status": "valid",
     "token": "DGyRejmCefe7v4NfDGDKfA",
     "validated": "2014-12-01T12:05:58.16Z"
   }

After setting up and testing the well-known payload on my end, I hit the challenge’s URL. This is the bit I am having a problem with.

If the status is “valid”, pebble requires an empty payload. e.g. an empty string “”

If the status is anything else, pebble requires an empty json object. e.g. a string of empty braces “{}”

My client is loosely based on Python library acme-tiny, so this may give better context:

• payload serialization for signed requests: https://github.com/diafygi/acme-tiny/blob/master/acme_tiny.py#L51
• hitting the challenge url: https://github.com/diafygi/acme-tiny/blob/master/acme_tiny.py#L146

In my use-case, if the challenge is “valid”, I need to send None… but if the challenge is another value I must send an empty Python dict {}.

So my questions are:

• should I be worried about the challenge status being potentially “valid” in production?
• am I taking the right approach by sending the empty payload if it is “valid”?

Thank you all in advance!

[_az]

@jvanasco

If the status is “valid”, pebble requires an empty payload. e.g. an empty string “”

If the status is valid, it means that the challenge is already fulfilled. You don't need to do anything.

By sending an empty string (""), you are not actually doing anything. You are in fact just doing a POST-as-GET operation - semantically equivalent to just GET'ing the challenge resource in ACME v1.

Conversely, when you send a payload of {}, you are responding to the challenge.

[jvanasco]

@_az

If the status is valid , it means that the challenge is already fulfilled. You don’t need to do anything.

Thank you again!

(sigh) I regretted basing my client on acme-tiny before. I regret it so much more now - there have been too many "lazy" details in it which have caused me issues over the years.

[jvanasco]

small followup…

1. when looping the authorization urls from the NewOrder, if the ‘status’ of a response is “valid”, I can skip the challenges - right?

2. would it be possible for a response to be “not-valid”, but a challenge’s status (within it) is valid? I assume not.

it seems like I can just short-circuit out, and based my client on a library that doesn’t safeguard against unnecessary requests.

[_az]

@jvanasco

when looping the authorization urls from the NewOrder, if the ‘status’ of a response is “valid”, I can skip the challenges - right?

You can create a new order, and in return immediately see an order status of ready.

This means that all of the order's authorizations are already valid - and you can immediately finalize the order.

In that case, you don't even need to loop over the authorizations.

But otherwise, yes, if you encounter an authorization that is valid, then you just move onto the next one.

@jvanasco

would it be possible for a response to be “not-valid”, but a challenge’s status (within it) is valid? I assume not.

Do you mean for an authorization?

I think maybe it's possible? For example, the authorization resource might be deactivated but one of its challenges might still be presented as valid.

But such a scenario has never presented itself to me when writing ACME clients tbh. I've always just responded to the challenge, confirmed that its status is valid (by polling until we hit valid, invalid or give up after some time), and assumed that the authorization has transitioned to the valid state as well.

Even if that assumption is violated, an error is going to occur at finalization anyway, so it doesn't really seem to matter in the end.