On 27/03/2026 17:18, William Lallemand wrote:
> On Fri, Mar 27, 2026 at 03:54:35PM +0100, William Lallemand wrote:
>> On Mon, Mar 09, 2026 at 07:39:43PM +0200, Mia Kanashi wrote:
>>>
>>> I'm thinking of this:
https://github.com/kanashimia/haproxy/tree/polling-fix
>>> Can you take a quick look at the first commit there? Should be easy
to read.
>>>
>>> Poll logic that used acme_res_challenge() will use acme_res_auth()
instead.
>>> It makes the code of acme_res_auth() quite a bit more messy though,
>>> as auth response contains an array of challenges, so finding a
correct one
>>> requires looping, but it is the correct logic.
>>
>> Since the Authorisation object contains the challenge objects, and
we're only
>> using 1 challenge, so the status of the challenge and the one of the
>> authorization is really 1:1.
>>
>> Are you seeing cases were this is problematic or would optimize
something?
>>
>
> I just checked the RFC again,
> https://datatracker.ietf.org/doc/html/rfc8555#section-7.5.1
>
> "Usually, the validation process will take some time, so the client will
> need to poll the authorization resource to see when it is finalized."
>
> Well, that's probably better then, if we could avoid URL recycling or
things
> like that.
>
Yes, RFC specifically mentions polling auth, and other ACME implementations
seem to poll auth too, partly because of recycling problems like these.
TBH I'm not entirely sold on this, but I figure following how everyone
does it
could cause less problems down the line perhaps.
For example Lego doesn't retry challenge unless it had a nonce error
as I remember.
> Be careful with pebble as this is really a simplified version, a too
simplistic
> approach could work with pebble but not with letsencrypt.
Yeah, just mentioned in passing, I'm trying to be robust with regards to it,
and handle buggy ACME implementations to some basic degree too.
There are many other CAs after all.
> > Also acme_res_challenge always read $.error.type but it should be
$.type
> > in case of a nonce error. And that "need a generic URN error
parser" comment
> > really needs fixing, if you had something in mind with regards to it
> > please tell.
>
> I agree, this is a more general problem with handling errors in ACME,
there no
> list of retryable errors and HTTP errors in the RFC for example.
>
ACME spec is underspecified in that aspect definitely.
> > I'm currently thinking of something like this:
> >
> > ret = acme_check_error(hc->res.buf, hc->res.status, "account", &trash,
> > errmsg);
> > if (ret == 1) {
> > if (!newaccount) {
> > /* not an error, we only need to create a new account */
> > if (strncmp("urn:ietf:params:acme:error:accountDoesNotExist",
> > trash.area, trash.data) == 0)
> > goto out;
> > }
> > goto error;
> > }
>
> We could have something like that yes, there's also the subproblem
objects
> which is not handled in the current implementation
> https://datatracker.ietf.org/doc/html/rfc8555/#section-6.7.1
>
> > That acme_check_error will write pretty error to the errmsg, but it
could
> > still be ignored afterwards if needed. Although I think haproxy
should do
> > hard fail on most of the URNs, that what other ACME impls do, and
only on
> > some like nonce errors should it retry, for that all res functions
need to
> > return enum acme_ret.
>
> I agree. Nonce are a particular case that need to be handled separately,
> currently we hard fail on nonce errors, but the newNonce logic must be
> splitted from the acme_process() function.
>
Thanks for the response!
