Personally, I think that's a more appropriate approach. Even if a protocol change was made that allowed an ACME client to pin the challenge to a certain IP address, the requested IP may not always be returned by the authoritative DNS server. Any type of latency, geo or weighted routing algorithm could potentially get in the way.
On Fri, Dec 04, 2015 at 12:46:01AM -0800, Peter Eckersley wrote: > There's a fairly good solution available with the current protocol, > which is to serve a (long lived) redirect from > /.well-known/acme-challenge/ on all of the servers to a different URL > that is always answered by the machine you run an ACME client on. > > Are there any cases where that is sufficiently unworkable to warrant a > protocol change? > > On Mon, Nov 30, 2015 at 06:17:21PM +0100, Jonas Wielicki wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > Hi list, > > > > I have asked this in the IRC and was pointed to this mailing list. I > > tried to get a certificate for klausurschokola.de via Let’s Encrypt > > during the currently running limited beta (we have the domain > > whitelisted). The name has the following address records: > > > > 1800 IN A 176.9.101.187 > > 1800 IN A 217.115.12.71 > > > > (in addition, there is one AAAA record for each of the machines > > addressed by the A records) > > > > As you can see, two different machines are addressed. Those are > > physically separated machines with different main administrators. > > Both are pulling their web content from the same source, but it is not > > supposed to be dynamic, so there is no "fast" (order of seconds) way > > to mirror the content. > > > > Our wish would be to be able to use different private keys and > > certificates for both hosts, and renew these independently from the > > other host. We thought that this would be possible using Let’s Encrypt. > > > > The problem is that currently, the Let’s Encrypt server sometimes > > chooses the wrong of the two IPs to ask for the file in > > /.well-known/acme-challenge. Ideally, it would use the IP of the > > requester (of course only after it has verified that the IP is in the > > DNS) or allow the requester to specify a preferred IP. > > > > For example, on 176.9.101.187: > > > > # letsencrypt certonly -c ~/schoko.ini -d klausurschokola.de -d > > www.klausurschokola.de > > > > [… curses …] > > > > Failed authorization procedure. klausurschokola.de (http-01): > > unauthorized :: The client lacks sufficient authorization :: Invalid > > response from > > http://klausurschokola.de/.well-known/acme-challenge/c5HJrtp8t8JhfNgTXVC > > 8N7OsCrguAWGw-JTIJxCFeIQ > > [217.115.12.71]: 404 > > > > > > Is such a thing planned? Are there security reasons against doing > > this? Are there security reasons against doing this on a DNSSEC signed > > domain (which klausurschokola.de is)? > > > > best regards, > > Jonas > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v2 > > > > iQIcBAEBCgAGBQJWXIShAAoJEMBiAyWXYliKJ1wP/iGVeGRxnAkrAstfjeGLvLeC > > TXnF76X/8xC3s4dd/UR0DE2n9Pdn0FYCK+6jRTn+Xpa0MvrA2ME20AZMh070Ghy0 > > JRbdTWqjQTHzvjXYQHjSkW24pyZNgdfnmwd0HiAhn1mANv3dhVTnHR4hibZww+Su > > ty3XzsyZYjrfQ3K5/bTb/jz+QZUoZ/fJJuNlyMsVInF3rzagj34WWR4sYbAIwKEF > > CTvBFxINY04pUeemYlywPYrUOmcJTOK/wVi1ya2BgLgTqNJP5FJOX5jCHHr8m5ej > > A7G/nGWFSybOG1GkjMOdST3uMeL7HlpqhUnuNzsiC3ZAfmgVwceLsG3bTCAxcrgB > > 7XiSs3MrURuEk17w2QB0Oyt487DrmftzFo3vzvCrrl42au9JV69Y14/0W3z5piYM > > DIGpd/KNSL2m6xvzoJHoi+o5lTl9GiP6KQKlJiIUtn2cz8Ro6CiwXkhD0FmG8sP7 > > 4wqg+vnpcTdhrzsWuAPrpGej+GT1LlWOLERnyPOfVhQ8EUPanwgUbGo1uTfHB2mj > > T2CdCCZhcmJFurvz+7FVI1WaVgGR/rdZbu4ueC+0YNZEOICXE0pIJEw8rKWJbqe3 > > lKchgpR6jR3TKHHwNFDIZj049TBiEGxMXsdEaGlLOHdnr4ZlIDgfycumhYVTNJUi > > IDHRifjFUchCynluOhZi > > =3akD > > -----END PGP SIGNATURE----- > > > > _______________________________________________ > > Acme mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/acme > > -- > Peter Eckersley [email protected] > Chief Computer Scientist Tel +1 415 436 9333 x131 > Electronic Frontier Foundation Fax +1 415 436 9993 > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
