On 04/04/2016 08:03 AM, Jaromil wrote:
>
> HK has a good setup based on the let's encrypt ACME client which is
> more minimal and thrustworthy. the intention is to use that, document
> it on the gitlab and then uniform use on all servers.
>

Here is how it works:

- on the server:
- an le system user with no login
- (optional) an ssh group allowed to SSH in
- HOME=/srv/letsencrypt
- ~le/acme-challenge is aliased to $DOMAIN/.well-known/acme-challenge
- ~le/certs/$DOMAIN hosts the certificates
- web server config for TLS looks for certs in
/srv/letsencrypt/certs/$DOMAIN/{cert,key,chain,fullchain}.pem

- on the client:
- an admin SSH account with key to sudo and ssh as le
- unlock le account (change shell to /bin/sh and optionally add to ssh
group)
- sshfs le@$DOMAIN:acme-challenge acme-challenge
- sshfs le@$DOMAIN:certs certs
- do the LE authorize dance (saves to acme-challenge/)
- do the LE cert dance (worked for all but files/vagrant)
- fusermount -u {acme-challenge,certs}
- lock le account (remove ssh group, shell to /usr/sbin/nologin)

The Letsencrypt part is run by letsencrypt-cli, a simple Ruby
implementation. It could use something else as well.

This should run on an "admin machine" to allow crontab outside of a
laptop. SSH agent forwarding could be used to avoid leaving keys on the
"admin machine".

==
hk

-- 
 _ _     We are free to share code and we code to share freedom
(_X_)yne Foundation, Free Culture Foundry * https://www.dyne.org/donate/