Subject: Re: [Acme] Wildcard certificate via http-01

From: "Matthew D. Hardeman" <[email-masked]>
Date: Wed, 24 Jan 2018 18:40:23 -0600 (CST)

You make your own case for using a mechanism other than this, though.

Your described use case of your domain strongly suggests routine frequent changes to your dns zone.

Presumably you’re already using a dynamic zone.  Or probably should be.

Your path to wildcard certs is probably better via dns-01.

> On Jan 24, 2018, at 6:04 PM, Alan Doherty <[email-masked]> wrote:
> 
> 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
> 
> 
> At 21:42 24/01/2018  Wednesday, Hugo Leisink wrote:
>> 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
>> 
>> 
>> _______________________________________________
>> Acme mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/acme
> 
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme