On Sun, 27 Sep 2026, at 11:05, Jérôme Billiras wrote: > Hi William, > > Good question. I used Let's Encrypt, both staging and production; > I haven't tested against another CA (ZeroSSL, Google Trust Services, > ...), so I can't say whether they'd behave the same way. > > I went back and dug a bit after your message, since I wanted to make > sure I wasn't missing something obvious on my end. Their > challenge-types page does mention this case [1]: > > "You can have multiple TXT records in place for the same name. For > instance, this might happen if you are validating a challenge for a > wildcard and a non-wildcard certificate at the same time." > > and a couple of threads on their community forum describe the same > shape of issue: two distinct authorizations, each with its own token, > sharing the same identifier value [2].
Thanks Jérôme & William I've experienced this too and IMHO it does need to be resolved, as there is no way to disambiguate the events and communicate a per-FQDN failure if one fails for some reason, but the other is successful. I wrote a blog post[1] about using 3.5-dev8 and it was a very positive experience, this was the only wart I ran into. I've deployed it now to all my homelab front ends! If my lua script[2] for CloudFlare is up to snuff I'd be happy to contribute it back as a patch, maybe we can modularise the core and just have small per-provider changes? A+ Dave [1]: https://people.freebsd.org/~dch/posts/2026-10-08-haproxy-acme/ [2]: https://gist.skunkwerks.at/dch/haproxy-acme-cf A+ Dave ——— Dave Cottlehuber
