The behavior allowed by the RFC 8555 ACME dns-01 validation method is a
strict subset of the behavior allowed by the CA/Browser Forum Baseline
Requirements Section 3.2.2.4.7 "DNS Change" validation method. That more
general method allows the validation token ("Random Value" in BRs parlance)
to be found in a CNAME record, and it allows the DNS record to be placed
either on an underscore-prefixed subdomain, or on the domain itself. The
CAs you are reselling from implement versions of the "DNS Change" method
that are not compatible with the stricter ACME spec.ACME does not aim to allow the full suite of possibilities allowed by all PKIs. It aims to offer an opinionated, easily-automated, obviously-secure collection of validation methods, which are collectively a strict subset of the validation mechanisms allowed by many different PKIs. I believe it is unlikely that ACME will support this form of negotiation in the future. That said, keep an eye on the "dns-persist-01" Internet Draft, which may allow negotiation of the Authorization Domain Name <https://github.com/ietf-wg-acme/draft-ietf-acme-dns-persist/issues/33>. Aaron On Fri, Mar 6, 2026 at 11:07 AM Jordan Rieger <[email protected]> wrote: > Dear ACME experts, > > > > We are developing an ACME server to help our customers purchase and manage > commercial certificates from us. Such automation is becoming more important > now that the maximum validity period has dropped to 200 days and will > eventually drop to 47. > > > > While we support free Let’s Encrypt certs in various ways, we currently > sell commercial certs only through our website. We resell them from > https://www.thesslstore.com/, which sources them from the DigiCert and > Sectigo CAs. Our ACME server is intended to be a wrapper around the > existing reseller API provided by The SSL Store for certificate > provisioning, allowing customers to use standard clients like certbot and > simple-acme to purchase and reissue certs from us via External Account > Binding. > > > > The issue I’m encountering is that when DNS validation is chosen, we get > “challenges” that must be published via TXT records *on the root domain > name rather than the _acme-challenge* sub-host. E.g. for a cert on > example.com, the CA will require us to publish a TXT token on example.com, > not _acme-challenge.example.com. Unfortunately, the ACME dns-01 challenge > type seems to have no way for the server to tell the client *not *to > prepend the conventional _acme-challenge label when publishing the TXT > record. There is also no way for us to tell the client to publish a CNAME > rather than TXT record, as required by Sectigo. This issue prevents us from > completing the domain validation (DV) process via our reseller API, because > the CA will not find the DNS record they’re expecting. > > > > It’s true that in most cases, we will control the domain’s DNS, as we are > the registrar of record and offer comprehensive DNS hosting; in that case, > we could first validate the client’s conventional _acme-challenge record > and then turn around and publish the CA’s requested record in the zone to > complete validation on that side. But there will be cases where the > customer uses a third-party DNS host, preventing us from publishing the > needed record. > > > > Do you know of any way around this issue, or any future RFC ACME extension > proposal that might help? I’m aware of the http-01 challenge type, but The > SSL Store reseller API doesn’t provide consistent support for HTTP > validation across all cert products. > > > > Thanks, > > > > Jordan Rieger | Software Development Manager | Webnames.ca > > > > > _______________________________________________ > Acme mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
