I don't have much to add, but... On Tue, Jul 16, 2019 at 05:44:39PM +0100, Stephen Farrell wrote: > > Hiya, > > On 15/07/2019 17:00, Ted Hardie wrote: > > Howdy, > > > > A reply in-line. > > > > On Sun, Jul 14, 2019 at 2:07 PM Stephen Farrell <[email protected]> > > wrote: > > > >> > > So, if I were personally configuring a similar system, I would avoid > > ..well-known, because it makes the information available to anyone who polls > > for it. > > Yep. OTOH so does the DNS once you know the name. > > > That gives information to an attacker about when the renewals are > > occurring and what the challenges are. They still need to successfully > > mount an attack to make use of it, but I don't see the reason to put that > > in a publicly accessible director. > > That did bother me a bit. My reasoning was that since the challenge > gets published in the DNS it has to be ok to publish it elsewhere. > > I was also a bit concerned that a bad actor can predict the timing, > but I think that's more down to the CA and the ACME client. With LE > for example, IIUC anyone can calculate likely times for renewal given > the current cert. It might be worth adding a bit of randomness in > there somewhere maybe. > > > I would probably personally use rsync > > of a directory with a similar check. If I had to use HTTPS for some > > reason, I would probably put it in a directory which required a distinct > > authorization from any other data on the web site and pull it that. > > That'd also work. In my case, I didn't want to have to configure > anything about the zone factory on the web server, just out of > sheer laziness:-) I considered maybe encrypting the challenges for > the zone factory (via PGP) as well, in case we ever end up with > some kind of challenge that'd need that, but in the end I guess > that's not needed. > > > > > The rest of this flow looks fine. > > > > A few minutes after that's done the web server (via a > >> another cronjob) checks if the correct new values have > >> been published in the DNS, and once it sees that's been > >> done, it finishes off the ACME renewal process with the > >> CA. > >> > >> Note that I'd be entirely happy to change the URL above > >> and/or the syntactic-sugar around the content expected to > >> be found there if there were a desire to document this. > >> > > If you did document this, I would suggest modifying it as above. I'm not > > personally sure that this is any value to making the directory a standard. > > I went for a .well-known for the same laziness reason - it > saves me having to configure anything except the name on the > zone factory.
.... just in case it's not clear to anyone, you shouldn't put anything in /.well-known unless you intend to register it or are willing to suffer the consequences of someone else registering it [for different use]. I don't have any arguments for or against /.well-known in this case that haven't already been mentioned. -Ben _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
