Kind of curious then, why there isn't any way to do the Wildcard challenge without API Access for DNS. Using this kind of delegation would make it possible to signal in DNS that there should be a special http challenge somewhere that would allow for a wildcard certificate. A DNS/HTTP challenge hybrid
For several years now, the Baseline Requirements set out a list of specific methods (the "Ten Blessed Methods") for how a CA may validate that the applicant is entitled to receive the certificate they've requested for a DNS name. It is not permissible for a CA to just do something else, even if there's an ACME feature that would enable it, unless it's listed as one of the Ten Blessed Methods (there are not in fact today ten of them) they mustn't use it for certificates in the Web PKI. In fact they're required to explicitly list which methods they use in their mandatory paperwork as a public CA.
To use a hypothetical automated DNS/HTTP hybrid, you would need to do all of (possibly proceeding in parallel) the following:
* Write up technically how it works. You likely want a complete ACME challenge method through the IETF process (ie you're writing an RFC probably with the ACME working group)
* Get both groups at CA/B (the public Certificate Authorities, and the Browser vendors) to vote in favour of a change adding this new method to the Ten Blessed Methods (section 3.2.2.4) with a condition allowing wildcards.
* Get at least one publicly trusted CA to actually offer your new method to subscribers for wildcard certificates.
This isn't at all impossible, but any two of those alone aren't enough to make it happen, you need all three. Personally I don't think this hybrid seems safe, and so I wouldn't support it, but I don't decide any of this.
I shared the same sentiment for a while, but then I thought about it a bit more. How would you implement a HTTP-based validation that really proves that you have control over all subdomains? You might think that you just have to extend the existing validation method to pick a random subdomain, but that won't work:
1. For many domains, you cannot just pick any random subdomain and expect that you can reach a server there.
2. For services where users share the same domain (e.g. *.github.io), proving ownership of a single random subdomain won't be enough, because you could just create that domain as a response to the ACME challenge. But that doesn't prove that you have complete ownership over github.io.
I cannot come up with any HTTP-based validation scheme that would prove ownership of all subdomains for a domain.
Either (a) no one thought of cross-protocol validation signalling, or (b) they thought of it and concluded that it was too convoluted and easy to screw up.
As to why no HTTP check, an observation from another recent thread on LE/ACME:
> For example, `nrmitchi.com` is pointed at Netlify. Netlify can obtain a certificate for `nrmitchi.com` (and `www.nrmitchi.com`, which is also pointed at them). It does not allow Netlify to obtain a cert for `.nrmitchi.com`, nor should it.*
