Add expires-field to response on challenge with immediate validation

Challenging the CA via http-01, we sometimes get a “valid” status in the response, instead of “pending”. In this case, it would be nice to add the same expires-field to the response like it would be updated in the authorization object after completing a challenge successfully.

This would save one round-trip (polling the authorization status via auth-uri and extracting expires-field from that response).

Hi @bytecamp,

Is this for an ACME client that you developed yourself?

I'm not sure I understand the reason for the request. In order to get challenge URLs to POST you have to have already seen the authorization object with the expires field, no?

Yes, the ACME client is self-written.

The expires-field in the authorization object is (per RFC) added after at least one challenge has been completed successfully. When doing a POST to a challenge uri, there are two possible responses from the CA:

  • 202 Accepted (status: pending)
  • 202 Accepted (status: valid)

In the first case, I have to check the authorization object at a later time. It can then be invalid or valid. If it is valid, then I can retrieve the expires-field and store the date locally.

In the second case, the challenge has already been classified as valid, so the authorization object is valid, too. In this case, I have to check the authorization object anyway just to extract the expires-field.

It would be nice to include the expiration date right into the response to the POST request to the challenge-uri iff the response is 202 Accepted with status valid.

with kind regards

Hi @bytecamp,

Aha. I think I understand better now.

This would be a feature request that should be directed to the mailing list for the IETF ACME working group. I believe the intention is to have clients poll the authorization to learn when it becomes valid and when it expires, not by looking at the response to the POST request to the challenge endpoint. I think the challenge POST should be seen as a request to initiate the challenge, not as a synchronous operation that is guaranteed to make the overall authorization immediately valid or invalid.

Thanks, I will forward my request to the IETF.

1 Like

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