On 19/02/2026 18:45, William Lallemand wrote:
> Hi,
Hiii, thanks for the reply :)
> Great! I'll take a look, but don't worry to much if some things are
missing
> functional, the ACME feature is still experimental in haproxy. I'll
take a look
> in more details.
Thanks.
> We are already able to print the DNS record in the log to put in the DNS
> challenge when doing ACME in "manual" mode, so we could probably do
something
> like that as well.
I've done similar here. With this challenge it makes more sense to create
dns account and records ahead of time though, from my understanding
acme.sh and lego-cli could be used for that in the future,
even for those who enter DNS manually could be nicer to do it AOT.
> This is really interesting as it would not require anymore to give
access to
> the reverse proxy to the DNS zone, one could just put manually the
token once
> for all.
> From the previous article it seems like this will be rollout in Q1
for staging
> and Q2 for production, so this is mostly ready for letsencrypt. Also
Pebble
> seems to support the specification, I used Pebble and step-ca during
> development for testing, so this should be easy to test with.
Yes, Pebble didn't support it at the time of writing that message.
I actually worked with letsencrypt guys on that to some degree,
provided feedback and fixed a couple of related bugs,
and tested against HAProxy implementation. :)
There was this one bug with JIT validation which I just fixed it,
waiting for Pebble support really did help to catch that.
Found that HAProxy tries to post poll challenge objects, which is
incorrect according to https://github.com/letsencrypt/pebble/issues/133
Also through Pebble I found a DoS condition, when the response is very big
HAProxy falls into the infinite loop of death and grief. IDK what is
going on.
When there are like 100 TXT records or more where accountid doesn't match
Pebble returns a very big error response and then HAProxy starts doing that
for some reason... But only sometimes! In some cases it just goto abort,
from that acme_process function. And when I try to use mitmproxy for logging
it always aborts...... Haven't tried to do gdb debugging yet.
> Well it's just changing iterating on 1 octet and you don't have to
handle > 10
> items so that's only inelegant more than inefficient. But I agree,
the API is
> not great. I stripped down our mjson code since the latest CVE, but
we could
> reintroduce mjson_next if needed.
Right, honestly it is inelegant either way, that mjson_next takes too
many args,
it would be better if there was some kind of struct mjson_iterator.
> I don't know about dns-persist-01, but that was a problem with dns-01
because
> the CA wouldn't allow a retry if the propagation was not done yet, and it
> requires to use a new DNS challenge which is really not efficient...
Interesting, thanks for the info. Well, here at least retrying again isn't
as much of a problem, as there is no dynamic token for response like with
other challenges, dns-persist-01 is pretty unique in that way, even if
you restart HAProxy without persisting cert, dns record would still be
the same,
as dns record binds to an account key, and account key doesn't change.
Still can be rate-limited though :P
dns-persist-01 also offers "JIT validation" as described here:
https://datatracker.ietf.org/doc/html/draft-ietf-acme-dns-persist#section-4.2
where CA can lookup DNS records and set status to valid immediately.
With it auth flow is Blazingly Fast (tm). It is optional though.
> We definitely need to check the propagation in this case, since there
won't be
> any manual commands on the CLI. But DNS would honestly take some time
to be
> ready for that.
Well, with the way I see this challenge being used, "wait for the
propagation"
step can be done ahead of time, during initial account and dns record
creation,
before HAProxy is even started, so it isn't required in that case,
and considering the fact that DNS records stay the same, can just try again.
In general would be interesting to see how people would actually use
that challenge in the wild.
> Or maybe we could differentiate the first generation from the renew,
and ask
> for manual validation only during the first generation.
But right, it is possible to differentiate first generation
based on the existence of the account key or a cert...
Account key not existing is a pretty strong indicator that it is a
manual setup
as it seems to me, and then it is possible to ask user for manual steps
similar to how manual dns-01 is done before DDoSing the CA.
Though it doesn't cover cases where account key already existed before,
or was changed, won't wait when you add new domain names to the cert after,
but well I print record information to the console anyways...
Maybe there is some way to improve that, not sure.
It is possible to rely on JIT validation too to see if manual steps are
needed,
like I already do in my feature branch. Sadly JIT validation is optional.
