Allow wildcard and private host certificates with non-DNS-01 challenges using DNS delegation?

I’ve been working on setting up DNS-01 validation for my domains, and in the course of dealing with the attendant complexity and difficulties compared to the traditional validation methods have found myself wondering why a simpler scheme wouldn’t suffice.

My understanding is that the two benefits the DNS-01 challenge provides over HTTP-01/TLS-ALPN-01 are that it allows issuing wildcard certificates and certificates for hosts that aren’t exposed to the public internet, and the reason that wildcard certificates for *.example.com can’t be issued after a successful HTTP-01/TLS-ALPN-01 challenge for example.com is that network delegation of a single subdomain through A/AAAA/CNAME records does not necessarily imply the intent to delegate control over the entire DNS tree rooted there.

I think that there’s a simpler way to achieve these same guarantees without running the entire ACME challenge machinery over DNS. As an illustrative example, here’s my understanding of the flow of a DNS-01 validation for a private domain when using a server like acme-dns to keep _acme-challenge records separate from your general DNS keys (a best practice in general, but especially relevant here because of the delegation involved):

  • the client initiates a DNS-01 validation for 8af994ff.private.example.net.;
  • the CA queries its DNS resolver for the records for _acme-challenge.8af994ff.private.example.net. and gets the CNAME response 7986e5ea-784a-452e-8bfe-14a51d23b0e8.acme-dns.example.net.;
  • the CA queries its DNS resolver for the authoritative nameserver for 7986e5ea-784a-452e-8bfe-14a51d23b0e8.acme-dns.example.net. and gets acme-dns.example.net.;
  • the CA queries acme-dns.example.net. for the TXT records for 7986e5ea-784a-452e-8bfe-14a51d23b0e8.acme-dns.example.net. and verifies the challenge.

My proposal is to add support for a CNAME record _acme-delegate that acts the same way a CNAME/NS record for _acme-challenge does, but for the existing HTTP-01/TLS-ALPN-01 challenges. You would add a record like:

_acme-delegate.8af994ff.private.example.net. CNAME acme-challenge.example.net.

with the meaning "ACME challenges for 8af994ff.private.example.net. should instead be directed to acme-challenge.example.net.". An example validation flow using this would be:

  • the client initiates a TLS-ALPN-01 validation for 8af994ff.private.example.net., requesting use of DNS delegation;
  • the CA queries its DNS resolver for the the records for _acme-delegate.8af994ff.private.example.net. and gets the CNAME response acme-challenge.example.net.;
  • the CA connects to acme-challenge.example.net. and runs a normal TLS-ALPN-01 challenge for the domain 8af994ff.private.example.net..

As far as I can tell, the two flows here are basically equivalent; this should have all the same guarantees with regards to zone authority that the existing DNS-01 challenge machinery does, but only require one-time DNS setup rather than dynamic TXT record adjustments for every renewal. The use of a specialized validation protocol like TLS-ALPN-01 avoids the need for complex DNS API integration with concerns about overpowered keys, TTLs, propagation, and so on, and allows for the elimination of the verbose UUID subdomains acme-dns relies on.

A wildcard certificate would correspond to _acme-delegate.*.example.com.; to make this valid we can map it to _acme-delegate-wild.example.com. instead, so that the simple case where you want example.com to be able to issue certificates for *.example.com could be expressed as:

_acme-delegate-wild.example.com. CNAME example.com.

Alternatively, the presence of an _acme-delegate record could be treated as delegating permission to issue a wildcard certificate, the same way DNS-01 _acme-challenge records currently work; this shouldn’t reduce expressivity, as you could still forbid wildcard issuance with CAA records, but it feels a little less orthogonal to me.

There are, of course, lots of bikesheddy debates to be had (should these be SRV records rather than CNAMEs? should _acme-delegate-wild imply _acme-delegate?), but it seems to me like this would allow for the issuance of private and wildcard certificates in a way that requires fewer moving parts than the existing DNS challenge machinery and integrates better with clients. It would also address one of the listed downsides of HTTP-01/TLS-ALPN-01 challenges – “If you have multiple web servers, you have to make sure the file is available on all of them.” – by allowing domains to opt in to delegating challenges elsewhere.

My feeling is all that this is too simple to not already have been thought of, so please feel free to explain to me why this obviously wouldn’t work!

First of all, there are limits to how a domain validation can be passed by CA/B Baseline Requirement Section 3.2.2.4. (v1.6.8 as of writing).
DNS-01 challenge is Section 3.2.2.4.7 DNS Change.
HTTP-01 challenge is Section 3.2.2.4.18/19 Agreed-Upon Change to Website.
TLS-ALPN-01 challenge is Section 3.2.2.4.10 TLS Using a Random Number.

The BR required that every HTTP validation file must locate in the Authorization Domain Name (including CNAME) or being redirected with HTTP status 3xx or being CNAMEd.

The method you suggested wasn’t allowed by CA/B Forum, which I guess is why Let’s Encrypt or other CA didn’t offer such feature.

2 Likes

That’s unfortunate but makes sense; I didn’t realise the CA/B requirements specified validation so precisely. Given that 3.2.2.4.19 basically includes ACME by reference I guess there’s still some hope for such a protocol to be standardized, but getting through CA/B is indeed a major obstacle.

Interestingly, it seems like the requirements HTTP-01 falls under actually permit issuance of wildcard certificates, so I guess a subset of this could be implemented to allow HTTP-01-validated wildcard certificates with a special DNS record, but it’s a lot less compelling if it can’t support private hosts or TLS-ALPN-01 challenges.

CA/B Forum allows issuance of wildcard certificate based on successful validation for the base domain (and some CA already implemented such). I think it’s Let’s Encrypt’s choice to not implement that option (for wildcard certificates, for now)
My guess for the decision is that it’s not beneficial for automation. (Consider the circumstance where subdomains are on another server, it’ll be hard for acme clients to automate the issuance when initiated from subdomain server). However, only Let’s Encrypt staff knows the reason behind their decision…

1 Like