Hi Mia,
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?
> Though by my testing Pebble always returns a single element array there.
Be careful with pebble as this is really a simplified version, a too simplistic
approach could work with pebble but not with letsencrypt.
> I'm double checking stuff against uacme and lego clients, just to be sureee.
>
> In comparison my previous attempt just skips the two stages,
> but doesn't fix the fact that HAProxy polls challenge endpoint.
Ok.
> 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.
> 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.
--
William Lallemand
