That was a concern I had as well. As such, I suggested the enhancement that in addition validation would have to occur on the base FQDN label over which the wildcard is being requested also.
In other words, to get a cert for *.example.com <http://example.com/>, I believe you should have to demonstrate file control over example.com <http://example.com/> and then at least a couple of randomly generated and unpredictable random_value1_here.example.com <http://random_value1_here.example.com/> and random_value_2_here.example.com <http://random_value_2_here.example.com/> addresses before the certificate could issue. > On Jan 24, 2018, at 5:37 PM, Thomas-Louis Laforest <[email protected]> wrote: > > Good day, > > I’m new to this so, if the comment is not appropriate I’m sorry. > > I do know of use case where the wild card certificate is requested as a way > for a domain owner to have SSL protection for all his current and future sub > domain without having any intention to actually host a wildcard http server > but numerous specific subdomain. > > It may event sure this is a good idea as this will expose, at least during > the authentication phase, a web service to have the load of any miswritten > subdomain web activity. > > I’m not sure if access to a specific http subdomain could be an effective way > to demonstrate effective full domain controls. > > For exemple, let say (no idea if this is active somewhere) a well know > organisation have a wildcard dns setting that goes to a subcontractor to > catch all mis label subdomain entry, this does not mean the subcontractor > http services has the authority to have a wildcard. (Let imagine a bank that > want to monitor miss label sub-domain). > > Thomas-Louis Laforest > >> Le 24 janv. 2018 à 16:58, Hugo Leisink <[email protected]> a écrit : >> >> Hi, >> >> While implementing ACMEv2 for Let's Encrypt, I noticed that wildcard >> certificates can only be obtained via dns-01. Because it's not possible >> for me to do that automatically, I proposed them a way to do it via >> http-01. After they said that 'it might work', they told me to contact >> you about this. >> >> My idea is that when a client requests a wildcard certificate >> (*.domain.tld), the CA server offers a challenge and requests that >> challenge via HTTP while using a random hostname (<long random >> string>.domain.tld). Because only a webserver with a website configured >> for *.domain.tld and with a properly configured DNS can respond to this >> challenge, it's enough proof that the request for a wildcard certificate >> is valid. Perhaps the CA server can do multiple requests with a new >> randomly chosen hostname for more proof. After all, they will all end up >> at the same website. >> >> The discussion about this at the Let's Encrypt forum can be found here: >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.letsencrypt.org%2Ft%2Fwildcard-certificates-via-http-01%2F51223&data=02%7C01%7C%7C483c89afae754bcc814808d56375907e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636524278950348118&sdata=bfdowfZL%2F7Mh3VHAK3KI3KZPVwzaILBvVc9O%2BtnGwq0%3D&reserved=0 >> >> I really like to hear your thoughts about this. >> >> Kind regards, >> Hugo Leisink >> >> >> _______________________________________________ >> Acme mailing list >> [email protected] >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Facme&data=02%7C01%7C%7C483c89afae754bcc814808d56375907e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636524278950348118&sdata=embcPP7vMGE%2FWEng4QrFi%2FP5hLYH0QB95EyzaIL73HI%3D&reserved=0 > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
