[Cryptography] letsencrypt.org

[Jason Cooper]

Hi John,

On Sun, Sep 17, 2017 at 10:13:40AM -0000, John Levine wrote:
> In article <20170914162618.GL31762 at io.lakedaemon.net> you write:
> >> Mine doesn't, it does everything as a low privilege user and then has sudo
> >> privileges to restart apache.
> 
> Same here.  The certs and keys go into a folder that belongs
> to the acme user that apache can read.  There's a similar setup
> for the smtp and imap and pop servers.
> 
> >So the certificate and keys are readable and writable by this
> >low-privilege user?
> 
> Well, yeah, that's how LE works.  It generates the keys and CSRs
> automatically.  The user's files aren't readable by any other user and
> it doesn't do anything but create and renew certs and doesn't allow
> outside login so I don't see it as weaker than any other
> software-based way to manage certs.

Oh, I wasn't asking as a critique of LE.  As I said, I've been using it
happily for quite a while.  I'm more interested in the specific client
choices that security-minded people are making.

Based on the responses to date, the only thing I see concerning (other
than unnecessary use of scripting[0]) is that the process with network
access is the same process/user as has access to the keys.

This is why I chose acme-client [1] (not the PHP acme-client, nor the
ruby acme-client, but the C one from BSD).  It is deliberately designed
from day one to protect the private keys.  Even in the event of
compromise via the connections to the acme servers.  From their website:

  You don't want the private key processes interacting with anybody else
  (acctproc.c, keyproc.c). You don't want network-touching processes
  interacting with the file-system (dnsproc.c and netproc.c). You don't
  want the process parsing (revokeproc.c) your certificate — which comes
  down the pipe and might be rigged to blow — to touch your file-system or
  the network. Same goes with the process converting the downloaded
  certificates to the format usable by your web server (certproc.c).
  Moreover, you don't want the process scribbling in your webroot to
  scribble elsewhere (chngproc.c). Same goes with the process scribbling
  in your public certificate directory (fileproc.c). 

I'm not advocating for one client over the other.  But I am saying that
individuals deploying clients, especially with automated updating, need
to set minimum criteria for security.  Then disregard clients that don't
meet that.  Personally, acme-client works for me, but ymmv.

thx,

Jason.

[0] "scripting" = "bailing wire and duct tape" :-)
[1] https://kristaps.bsd.lv/acme-client/