]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/MEDIUM: acme: stuck ACME task when authz is already "valid"
authorWilliam Lallemand <wlallemand@haproxy.com>
Wed, 10 Jun 2026 16:06:57 +0000 (18:06 +0200)
committerWilliam Lallemand <wlallemand@haproxy.com>
Wed, 10 Jun 2026 16:19:55 +0000 (18:19 +0200)
commit0a90ff6b3da92aab23949fca221702989dfe7fa9
tree1416ed4e4922e7b30c092f80cca884f3f70cd9cb
parent6c75202b480de2053f848aba144a74ec3b25b3ce
BUG/MEDIUM: acme: stuck ACME task when authz is already "valid"

When an ACME order is re-used or when a domain was recently validated,
the CA may return status "valid" for an authorization without requiring
any challenge to be solved.  In acme_res_auth(), this is handled by
setting auth->validated = 1 and jumping to out — but auth->ready is
never initialized and stays 0.

This became a bug in 3.4 when the "challenge-ready" option and the
ACME_CLI_WAIT state were introduced (commit 2b0c510aff).  ACME_CLI_WAIT
computes:

    all_cond_ready &= auth->ready;

across all authorizations.  A single auth->ready == 0 drives the AND
to zero and the task waits indefinitely for a readiness signal that
will never arrive, since no challenge was published and no external
agent will ever call challenge_ready() for that domain.

Fix it by setting auth->ready = ctx->cfg->cond_ready for already-valid
authorizations, marking them as satisfying all required readiness
conditions so ACME_CLI_WAIT can proceed normally.

This should be backported to 3.4.
src/acme.c