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 protected]> 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 protected] >> https://www.ietf.org/mailman/listinfo/acme > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
