I'm proposing a new challenge type that I think would be compatible with wildcard domains:
Certbot (or manual process) requests a TOKEN from the Let's Encrypt servers for validating e.g. a certificate with subject alternative names { example.com, *.example.com, example2.com, *.example2.com }.
Certbot (or manual process) places the TOKEN accessible over port 80 so that it can be fetched from all of the following URLs:
where the UUIDv4 is an UUID version 4 identifier decided by Let's Encrypt immediately before checking the TOKEN so the server must be able to serve it without previous knowledge of subdomain name (which is the whole idea of wildcard domain). The use of UUID v4 avoids collision with any existing subdomain name and tests true wildcard behavior. This could be also trivially extended to test that the response is the same from multiple locations and/or different values of UUID v4 selected.
The cert would be signed after testing that all the URLs returned correct TOKEN value.
This would allow easily getting and renewing wildcards certificates spanning over multiple domains and it would be compatible with systems running behind load balanced reverse proxies and without requiring dynamic API to change DNS records.
Unlike the previous method, this literally tests that the HTTP wildcard end point is under control instead of ability to install invalid cert or control DNS.
I would guess he was assuming there's already a wildcard DNS entry setup that corresponds to the wildcard name in the cert so no additional DNS records would be necessary. Though I'd guess there are plenty of people getting wildcard certs that don't need or want a corresponding wildcard DNS entry.
But yeah, this only seems to makes sense if you don't have to manipulate DNS records at renewal time.
Getting a wildcard certificate using the http-01 challenge is explicitely forbidden by the CA/Browser Forum Baseline Requirements since the end of 2021. Before that it was possible, but it was decided (how and why I don't know) that HTTP challenges weren't valid any longer.
So my guess is that any HTTP based challenge won't be good enough for wildcard certificates.
This is a bad interpretation and a bad conclusion.
The CA/B Forum did not forbid all HTTP challenge mechanisms for wildcards. The CA/B forum prohibited the existing HTTP challenge mechanisms from being used for wildcards - specifically because they were vulnerable to a particular attack vector.
The mechanism proposed by @mtrantalainen would constitute a new challenge type, and is designed around that attack vector. It would likely need to be formalized through an RFC, and proposed to the CA/B forum by one or more integrators. I don't see any reason why the CA/B forum would oppose it, as no security concerns seem to jump out - but I haven't thought about this much.
That being said, IMHO, I don't foresee this idea getting much traction with LetsEncrypt or other CAs for the reasons @rmbolger and @9peppe noted. It would only be useful if there were a wildcard DNS entry set up that points to a specific server AND a HTTP server with either: (i) a default host; or (ii) the ability to add new hosts. A default host would likely cause issues with race conditions in many environments, and adding new hosts could create excessive downtime with many servers as Certbot (or other clients) would need to restart the HTTP servers. Restarting servers would be necessary, because configuration reloads and "graceful" restarts on multi-process/forked servers typically do not guarantee the next request would be served by a "new" or "old" process. In any other situation, one would be better off with the other methods as this would entail manipulating DNS records in the same way as DNS-01, followed by a HTTP-01 verification (i.e. it's twice the work!).
Perhaps we're all missing something here, but the proposed mechanism seems like it would have very limited utility.
