letsencrypt/pebble

Pebble seems to reuse challenges object for different orders

galdor opened this issue · 2 comments

galdor commented

I discovered something interesting about Pebble:

  1. I submit an order for a certificate for DNS name localhost, solve the challenge, finalize the order, download the certificate chain, all good.
  2. I submit a new order with the same DNS name (but different notBefore/notAfter parameters); the order contains the same challenge URIs (well at least the same URIs for the challenge I use, HTTP-01).
  3. I tried to notify Pebble that I'm ready to solve the challenge; the call fails with error urn:ietf:params:acme:error:malformed, "Cannot update challenge with status valid, only status pending".

This seems to indicate that Pebble kept the challenge object from the first order, and its status is valid since it was indeed solved for the first order.

Is this expected behaviour? Does it mean I should always expect a challenge to be potentially valid before I try to solve it? It would not be unreasonable: the server may remember that my account solved a challenge for a specific authorization identifier, and does not need the client to re-solve it. But I cannot find anything saying that a newly created authorization object may contain existing challenge objects in RFC 8555.

aarongable commented

Is this expected behaviour? Does it mean I should always expect a challenge to be potentially valid before I try to solve it?

Yes, this is expected. This behavior is called "authorization re-use", and both Pebble and Boulder implement it. RFC8555 Section 7.4.2 describes "pre-authorization", a mechanism by which an ACME client can create an authorization independent of creating an order. This feature would be useless if the new-order process were not capable of using pre-existing (and perhaps already-validated) authorizations. Therefore we implement authorization re-use.

ACME clients should abide by the instructions in Section 7.4. Namely, always check the status of the order. If it is already Ready, then there is no need to perform any validations.

But I cannot find anything saying that a newly created authorization object may contain existing challenge objects in RFC 8555.

These are not newly created authorization objects. They are newly created order objects, containing pre-existing authorization objects, which then (of course) contain the same challenge objects as they always have.

galdor commented

Got it, it makes sense. Thank you for the very clear explanation!