Subject: [Acme] Wildcard certificate via http-01

From: Hugo Leisink <[email-masked]>
Date: Wed, 24 Jan 2018 22:42:07 +0100

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://community.letsencrypt.org/t/wildcard-certificates-via-http-01/51223

I really like to hear your thoughts about this.

Kind regards,
Hugo Leisink

---

From: "Matthew D. Hardeman" <[email-masked]>
Date: Wed, 24 Jan 2018 17:32:31 -0600

I believe the mechanism described here would run afoul of the present baseline requirements, but could be brought into line with the BRs merely by validating control over the base domain.tld that wildcard is being requested for. Current BR method #6 specifies that control over a given FQDN demonstrated by website change is sufficient validation for all FQDNs ending with the validated label, thus appropriate to use in validation for wildcards.

Despite the BRs clarity on that matter, that mechanism leaves much to desire.  There’s no strong logical reason to presume the administrator of example.com <http://example.com/> should be entitled to a certificate covering billing.example.com <http://billing.example.com/> or *.example.com <http://example.com/>.

Additional security enhancement as described in this method in which additional random labels are added to the base domain — for domain names unknown to the applicant until time of the validation request would seem to illustrate broad-sweeping control over the validated main label + 1 level beyond. Perhaps validate the base domain over which validation is requested plus 3 random labels beyond?

I will say that just as with TLS-SNI-0x, there were certainly surprises in the initial deployment of http-01 that led to changes (only validate over port 80 initially because of esoterica in shared hosting environments, etc.)

Those kinds of issues suggest that any kind of validation over HTTP — and especially contemplating new or enhanced privilege in HTTP validations — should entail some sort of study of actual real-world deployment behaviors in a wide plurality of environments which exist on the web today.  I’m not sure how best to define or architect that, but it’s clear that significant real world behavior in deployment of HTTP and HTTPS services deviated from the expectations and assumptions of the group in previous validation method work.

> On Jan 24, 2018, at 3:42 PM, Hugo Leisink <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Thomas-Louis Laforest <[email-masked]>
Date: Wed, 24 Jan 2018 23:37:52 +0000

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-masked]> a écrit :
> 
> Hi,
> 
> 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
> 
> 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

---

From: "Matthew D. Hardeman" <[email-masked]>
Date: Wed, 24 Jan 2018 17:50:37 -0600

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-masked]> wrote:
> 
> Good day,
>

---

From: Alan Doherty <[email-masked]>
Date: Thu, 25 Jan 2018 00:04:22 +0000

I would second this proposal
but as for all my domains where we need wildcard certs do not have wildcards in dns

like I instruct users to pop from username.pop3a.example.org smtp to username.smtps.example.org
or https api to api-key.api.example.com for other stuff

specifically so when username/api-key is deleted/revoked his dns fails and he stops bothering our servers (as he will inevitably never tell gmail or other webclient stop ;) 
so rather than have huge san certs we'd prefer *.pop3a.example.org on our tls certs
(we have a http listener for *.pop3a.example.org and *.smtps.example.org that redirects to our pop3 and smtp help page (that we could respond to acme challenges on easily)

that said I now see we could easily do

deleted.pop3a      A 127.0.0.1
deleted.smtps      A 127.0.0.1
*.pop3a            A our.rea.lip.add
*.smtps            A our.rea.lip.add
but then users could (thus would) setup random-typo.pop3a.example.org in their clients and we'd be none the wiser till we try and swat them years later as dead users ;)

but I guess much like DNS-01 we could add a temporary wildcard to dns for the time needed for the authentication to succeed then remove afterward (and during the period also see how many ex-users are still retrying ;) )

but dns-01 will likely still serve us better

but I still approve for those with actual wildcards in their actual zone files for whatever reason

but for those with wildcard in dns simply connecting to http://random.wildcarddomain.com/.well-known/acme-challenge/whatever
once for ownership
then dns lookup of random1.wildcarddomain.com random2.wildcarddomain.com random3.wildcarddomain.com
to verify same ip(s) returned should prove the wildcard exists
if ips differ only then should it be necessary to follow up with http gets (say its got dns loadbalancers or summit)
 http://random1-3.wildcarddomain.com/.well-known/acme-challenge/whatever