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]. For what it's worth, it also looks like other ACME clients have run into this the hard way at some point: acme.sh had open issues about DNS hooks overwriting the first TXT record instead of adding a second one [3], and cert-manager had a similar report about its Azure DNS and Route53 providers replacing the whole record instead of appending to it [4]. Not saying that settles it, just sharing what I found in case it's useful context, since it looks like the same kind of trap PR #418 is trying to avoid for the OVH provider. Anyway, I fully get that this touches something that was done on purpose, so please take the time you need. Happy to test against anything you'd like me to check on my setup in the meantime. Thanks, Jérôme [1] https://letsencrypt.org/docs/challenge-types/#dns-01-challenge [2] https://community.letsencrypt.org/t/ordering-a-cert-for-wildcard-and-root-together-requires-two-dns-challenges/212379 [3] https://github.com/acmesh-official/acme.sh/issues/1261 [4] https://github.com/cert-manager/cert-manager/issues/4250 > Le 27 sept. 2026 à 01:55, William Lallemand <[email protected]> a écrit : > > Hello, > > On Sat, Sep 26, 2026 at 09:25:53PM +0200, Jérôme Billiras wrote: >> Subject: [PATCH 2/2] BUG/MEDIUM: acme: only mark one challenge as ready per >> call >> A certificate covering both a domain and its wildcard, for instance >> "example.com" and "*.example.com", gets two dns-01 authorizations from >> the ACME server. Both have the same identifier value, "example.com" >> (the wildcard one only has "wildcard": true), but each one has its own >> token, so two different TXT records must be deployed under >> "_acme-challenge.example.com". >> > > What ACME provider did you used to end up with this case? > > The code was done this way because our tests ended up with the same challenge > for both "example.com" and "*.example.com". So that mean we should handle both > cases. > >> [...] >> @@ -3604,11 +3606,13 @@ int acme_challenge_ready(const char *crt, const char >> *dns) >> if (ctx->cfg->cond_ready & ACME_RDY_CLI) >> auth = ctx->auths; >> while (auth) { >> - if (isteq(ist(dns), auth->dns)) { >> - if ((auth->ready & ACME_RDY_CLI) == 0) { >> - auth->ready |= ACME_RDY_CLI; >> - found++; >> - } >> + /* Only mark one challenge per call: a domain and its wildcard >> + * have two different challenges sharing the same <dns>. >> + */ >> + if (!found && isteq(ist(dns), auth->dns) && >> + (auth->ready & ACME_RDY_CLI) == 0) { >> + auth->ready |= ACME_RDY_CLI; >> + found++; >> } > > Something like this should do, but this is changing the behavior which was > intentional, this will probably break things for people, so we must be > careful. > > This also mean that the dns check can't work correctly either. I'll do more > testing. > > Thanks, > > -- > William Lallemand
