[Acme] Re: Custom hostnames for dns-01 challenges (not just _acme-challenge.example.com)

[Jordan Rieger <[e-mail]>]

That makes sense, Aaron. Thank you for the comprehensive overview.

 

From: Aaron Gable <[e-mail]> 
Sent: March 6, 2026 2:27 PM
To: Jordan Rieger <[e-mail]>
Cc: [e-mail]
Subject: Re: [Acme] Custom hostnames for dns-01 challenges (not just _acme-challenge.example.com)

 

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 <[e-mail] <mailto:[e-mail]> > 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 <http://example.com> , the CA will require us to publish a TXT token on example.com <http://example.com> , not _acme-challenge.example.com <http://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 -- [e-mail] <mailto:[e-mail]> 
To unsubscribe send an email to [e-mail] <mailto:[e-mail]>