Subject: [Acme] Musings on a transparent ACME client

From: Noah Kantrowitz <[email-masked]>
Date: Mon, 7 Dec 2015 11:56:34 -0800

I wrote up some thoughts that have been brewing in my head for a bit on making a truly transparent/generic ACME client, would love more eyes on it in the hopes I've missed an option here: https://coderanger.net/better-lets-encrypt/

--Noah

---

From: Peter Eckersley <[email-masked]>
Date: Mon, 7 Dec 2015 12:12:02 -0800

One thing I'll say that we've learned from supporting the official
letsencrypt client is that different types of "simple" work for
different people.  On Ubuntu 14.04, which is our most popular platform,
The breakdown of authenticator plugins used when successfully obtaining
certs is like this:

34% use the Apache plugin (also supports cert installation)
32% use the "standalone" plugin
23% use the "webroot" plugin
6%  use "manual" plugin
5%  use the third party Plesk plugin (also supports cert installation)

Similarly in support forums, when people have trouble but can be helped
across the line, it's a pretty diverse set of methods that wind up
working for them.

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

-- 
Peter Eckersley                            [email-masked]
Chief Computer Scientist          Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993

---

From: Eric Mill <[email-masked]>
Date: Mon, 7 Dec 2015 17:00:18 -0500

Would a DNS-based validation process (part of the ACME spec, but not yet
implemented for LE) make your problems go away?

-- Eric

On Mon, Dec 7, 2015 at 3:12 PM, Peter Eckersley <[email-masked]> wrote:

> > I wrote up some thoughts that have been brewing in my head for a bit on
> making a truly transparent/generic ACME client, would love more eyes on it
> in the hopes I've missed an option here:
> https://coderanger.net/better-lets-encrypt/
> >
> > --Noah
> >
>
>
>

-- 
konklone.com | @konklone <https://twitter.com/konklone>

---

From: Noah Kantrowitz <[email-masked]>
Date: Mon, 7 Dec 2015 14:08:56 -0800

No, the way these tools would get used is on the actual edge/termination servers which I generally wouldn't want to give access to DNS for security reasons. DNS validation would definitely help with zero-downtime updates overall though, but require some level of central command and control system to keep it all organized. That would be awesome for people using primarily API-driven termination points though, like AWS ELBs or a Fastly CDN.

--Noah

> On Dec 7, 2015, at 2:00 PM, Eric Mill <[email-masked]> wrote:
> 
> Would a DNS-based validation process (part of the ACME spec, but not yet implemented for LE) make your problems go away?
> 
> -- Eric
> 
> konklone.com | @konklone

---

From: Hugo Landau <[email-masked]>
Date: Tue, 8 Dec 2015 01:47:53 +0000

> I wrote up some thoughts that have been brewing in my head for a bit on making a truly transparent/generic ACME client, would love more eyes on it in the hopes I've missed an option here: https://c…

Honestly, I think it makes more sense to specify a standard location for
challenge files on the system (I'm currently using
/var/run/acme/acme-challenge) and design your software to serve requests
for /.well-known/acme-challenge/ on it. If the location of challenge
files is standardised, this alias can become a default for many web
servers, frameworks, etc. It's similar to the standard "Alias /cgi-bin/
/usr/lib/cgi-bin/" of yesteryear, though hopefully with less security
issues.

---

From: Noah Kantrowitz <[email-masked]>
Date: Mon, 7 Dec 2015 18:00:34 -0800

> On Dec 7, 2015, at 5:47 PM, Hugo Landau <[email-masked]> wrote:
> 

Perhaps in the fullness of time that could help, but stuff like stunnel is unlikely to ever support such things. Regardless, at this point in time, making assumptions about web server config will only work for the simple cases and I want to get as many people switched over to LE (and ACME-d friends) as I can.

--Noah