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 protected]
>https://www.ietf.org/mailman/listinfo/acme

_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme

Reply via email to