I’m updating my client for ACME v2 and saw that the server only offers dns-01 challenges for wildcard certificates. That’s not really an option for me. What is the reason for not offering a http-01 challenge? What if the server comes up with a random hostname for the requested domain and use that for the challenge? For example 843c404f…53133ed2.example.org. I think that’s enough to allow me to prove that my webserver is hosting *.example.org. Looking forward to hear your thoughts.
I believe the current position of Let's Encrypt is that it's simply not going to happen:
If you need wildcard using HTTP validation, you still have the option of going to a commercial CA, most of which will happily sell you a wildcard validated over HTTP.
1 Like
@_azis is correct: we’re very unlikely to offer that option, even though it would be allowable under the BRs. Right now our feeling is that the DNS challenge more closely matches the assertion made by a wildcard certificate, and is much simpler than a randomized hostname http approach.
It’s definitely not simpler, because not every DNS provider has an API for making changes and there is no standard for such API. I respect LE’s choice for not offering http-01, but that leaves me no choice than to ignore the wildcard certificate option.
One example of a hosting environment where HTTP-01 isn’t a good match for wildcards would be one where users are allowed to automatically register any subdomain of their choice. In that case, if LE provided two or three challenge subdomains, a user could immediately register each of them and satisfy those challenges. If a wildcard could be issued on that basis, an ordinary user would then be able to receive a wildcard certificate for the base domain.
I don’t agree that this is a valid argument. If a user is allowed to register any subdomain, than it’s valid to offer that user a wildcard certificate since he/she is theoretically allowed to register all possible subdomains. With your argument, you’re trying to solve an issue that 1) is not an issue or 2) should not be solved by LE.
But that user isn’t allowed to register subdomains that have already been registered by other people, even though those would be covered by the wildcard. For example, MIT allows students to register arbitrary names of their choice under mit.edu, but they’re not allowed to register names that have already been registered by others—such as web.mit.edu. An MIT student can, as far as I know, register all possible new subdomains of mit.edu, yet should still not be given a wildcard certificate for that domain by a CA.
5 Likes
Than still there is no problem. A student can register as many hostnames under mit.edu as he wants, he probably won’t get a *.mit.edu website in the webserver configuration from the mit.edu webmaster. So, when LE uses [long random string].mit.edu as the challenge, it will fail. Only someone who owns a website with *.mit.edu in the webserver configuration will pass that challenge.
It sounds like you’re proposing a model where the CA doesn’t tell the applicant what the challenge domain names are before using them. All of the existing challenges do tell the applicant what the challenge names will be. For example, in HTTP-01 you get told exactly what name (and URL) you have to be able to be able to respond for.
It’s possible that a particular site doesn’t make it very fast to activate a particular name, but in ACME the applicant gets to tell the CA when the challenge is ready to be tested.
In case of a request for a wildcard certificate, the LE server tells the applicant what file with what content will be requested, but it will not tell what hostname it will be using. That way, only servers that already have a website configured for *.domain.tld and with the correct DNS settings will pass that test. To make the test more reliable, the LE server can do multiple requests for different hostnames. All a different .domain.tld. To me that proofs enough that your DNS and webserver are valid for *.domain.tld.
A site doesn’t have to activate a particular name during the certificate request procedure, because when done right it already has a website configured for *.domain.tld. All modern webservers allow a hostname with a wildcard in the configuration.
That might work; I’m not sure whether that approach was considered at the ACME WG. You’re welcome to discuss it there or maybe someone who was part of the ACME WG wildcard discussion can indicate whether that approach has already been discussed.
Where or how can I reach this ACME WG?
I sent my proposal to them. The discussion can be found at https://mailarchive.ietf.org/arch/msg/acme/m_B85N6Q7-rT1vD7c3AWolWN3OM, although for some reason the messages sent to the mailinglist can’t be read at the moment (Error reading message file).
Interesting discussion. Some thoughts:
I can already permanently delegate dns-01 challenges for wildcard certificates to another DNS server by setting-up the _acme-challenge record as a CNAME (https://github.com/joohoi/acme-dns) [or possibly even as an NS record].
I therefore think that it would not be less secure if I could permanently delegate challenges for wildcard certificates to an HTTP server. Why should an HTTP server referenced in my zone be less trustworthy than a DNS server referenced in my zone? (Or: Why is an “ACME-DNS” instance installed on my own server deemed more trustworthy than Apache/nginx installed on my own server?)
I’m thinking of an upgraded http-01 challenge with the following modification: Wildcard certificates may be issued by this modified http-01 challenge if an _acme-wildcard DNS TXT record with value 1 exists for the given domain (and the usual file challenges succeed).
Why I think this makes sense: I think HTTP challenges are easier to handle for most admins than DNS challenges. DNS challenges require fiddling with the API of a (remote) DNS server to create + delete records and then wait for them to actually show up whereas HTTP challenges usually only have to put some files into a local folder. Furthermore, it would be nice if my HTTP server wouldn’t have to know my DNS credentials.
Maybe I’m missing something?
1 Like
I think the real difference here is, that when validating using DNS, the CA has a reason to assume that you indeed have control over the domain, or you have been delegated authority to answer the challenges (CNAME). However a domain might have a wildcard A/AAAA record covering all subdomains except a few named ones.
For example, the domain admin might want to run mail servers at mail.example.org and point every other subdomain except mail to the webserver, because of a service that autogenerates subdomain vhosts for example. In this scenario, it would wrong for the web server to be able to autonomously validate control over all subdomains (including mail), because this decision of separation is made in the DNS. From the CA perspective, it would be impossible to iterate over all possible subdomains in order to verify that the webserver indeed has a claim over all of them.
Pointing every other subdomain to the webserver can be done two ways:
-
The domain admin can create every subdomain as an individual DNS record. That way, applying for a wildcard certificate via http-01 won’t work, because only those subdomains explicitly appointed to the webserver will work. And that’s is correct. So, using http-01 to obtain a wildcard certificate won’t cause an issue here.
-
The domain admin can create a DNS record for mail.example.org and a wildcard record which points to the webserver. In that situation, the webserver admin can obtain a wildcard certificate via http-01. Also in this case, there is no issue. The webserver obtained a wildcard certificate in a valid way, because it matches the DNS setting (both contain *.example.org). Yes, although it should not be valid for mail.example.org, but since the DNS already catches that case, it’s all fine.
Don’t see a wildcard certificate as an ‘own-it-all’ thing, but as an ‘own-the-remaining’ thing. The DNS is the authority in this case. Giving a wildcard certificate instead of several subdomain certificates is just a convenience.
Unfortunately 'own-it-all' is exactly what it's for, and how it works from the client validation perspective.This would allow whoever controls the web server to impersonate mail.example.org in MITM situation for example.
This is exactly why misissued certificates are important to get revoked ASAP, even though the DNS records point to the correct addresses.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.