
Let's Automate Let's Encrypt - eth0up
https://www.linuxjournal.com/content/lets-automate-lets-encrypt
======
warcode
I just used [https://certbot.eff.org/](https://certbot.eff.org/)

Put "certbot-auto renew --quiet --no-self-upgrade" in crontab and it does its
own thing.

~~~
grawlinson
Visiting that website was eye opening.

Previously I had a monthly crontab script that updates my LE cert, but now it
seems that certbot has been backported to my server's OS (Debian Jessie) which
makes my script redundant.

I'll be glad to retire my script. :)

------
StavrosK
All the Let's Encrypt automation I want to see is:

sudo service nginx start

And nginx gets/renews certificates automatically.

~~~
jaas
That's where we'd like to see things go as well. Same for Apache. -Josh, head
of Let's Encrypt

~~~
X86BSD
Right this is exactly what the Letsencrypt folks are trying to solve. Thank
you for your work Josh! SSL has been a pain in the ass for decades! Generating
certs, deploying them, maintaining them. This is why we are not at 100% SSL on
the web. The LE folks are trying to fix this. Please send a few dollars their
way on their fund raising page to help this goal along.

It's not unobtainable to make using certs MUCH easier and automated, their
work should be supported by us all.

------
thaumaturgy
We've fully automated Lets Encrypt on our handful of servers and so far it
works really well, with only a few glitches. It's specific to our setup but:

-> We do DNS verification through Dehydrated ([https://github.com/lukas2511/dehydrated](https://github.com/lukas2511/dehydrated)). Because we use in-house DNS running PowerDNS with a MySQL backend, updates to records are a cinch.

-> Dehydrated has "hooks" that allows you to call your own scripts for each step of the verification process. We have an on-prem sysadmin box that does remote administration of the servers (so that none of our servers have direct access to any other server, just in case of a breach), so we just had to update a few commands to work with Dehydrated's hooks.

-> Each remote server has its own directory within the Dehydrated environment, and there's an "update" script that runs from cron that: a) asks that particular server which hostnames it currently has, b) updates the hostname list in that server's Dehydrated directory, and c) invokes Dehydrated.

Because we host some client sites, it felt skeezy to me to be updating files
in their web directories on a regular basis even if it's really temporary. DNS
updates however are just fine.

All in all Letsencrypt has been a huge, huge win for us. I'm really grateful
for both them and for Dehydrated.

------
misiti3780
Can someone explain to me the following

1) Why did it take so long for an open source version to come into existence ?
(there must have been some serious hurtles Let's Encrypted had to overcome to
do this)

2) Given that you can get LE certs for free and use certbot for auto-renewal,
why is anyone purchasing certs anymore ?

~~~
rabbitfang48
> 2) Give that you can get LE certs for free and use certbot for auto-renewal,
> why is anyone purchases certs anymore ?

Let's Encrypt only offers Domain Validation certificates, not Organization
Validation or Extended Validation (green bar) certificates [1]. The
certificates themselves are only valid for 90 days, which might pose a problem
for organizations where their infrastructure makes changing certificates
difficult or time consuming. LE does not offer wildcard certificates [1], and
there is a rate limit of 20 certificates per week per registered domain [2],
so organizations with too many domains won't be able to use LE for all their
certs.

[1]: [https://letsencrypt.org/docs/faq/](https://letsencrypt.org/docs/faq/)
[2]: [https://letsencrypt.org/docs/rate-
limits/](https://letsencrypt.org/docs/rate-limits/)

~~~
Torgo
This is basically where I am. I have a VPN appliance I have to maintain. It's
a manual process to update the certificate. Just about everything else I use
runs LetsEncrypt, but this VPN box has a nine dollar cert from Namecheap
because nine dollars is totally worth not having to manually deal with the
certificate replacement more often than once a year.

------
zokier
As everyone is mentioning their favorite tools, I like acmetool[1] in
particular. I began to work on a docker/compose/nginx integration[2], but
never finished it due shifting priorities. The missing piece was a reload hook
for nginx. It would have been easy with simple cgi script (just send nohup),
but alas, nginx does not support cgi.

[1] [https://github.com/hlandau/acme](https://github.com/hlandau/acme)

[2] [https://github.com/zokier/acmetool-
docker](https://github.com/zokier/acmetool-docker)

~~~
fpoling
To integrate my acme client with nginx running in a separated Docker container
I started nginx together with a shell script that reads from a named pipe and
then sends signal to nginx to reread configuration. Then the client writes to
the pipe when it gets a new certificate.

~~~
zokier
That sounds like it would work just fine. I personally took kinda dogmatic
approach and tried to avoid having several (long running) processes in a
container. As such I think a embedded Lua script in nginx would have been most
suitable solution

~~~
fpoling
If you have Docker 1.12 or later you can run your acme client in the same
process namespace as the nginx container. Then the client can signal nginx
directly about certificate change.

------
kozikow
I use [https://github.com/jetstack/kube-
lego](https://github.com/jetstack/kube-lego) and so far it works . I didn't
get the to 90 day expiry yet, but it successfully automatically acquired the
first certificate. I heard good things from people who have been using it for
a while.

I recommend the nginx as ingress backend ( [https://github.com/jetstack/kube-
lego/tree/master/examples/n...](https://github.com/jetstack/kube-
lego/tree/master/examples/nginx) ), as GCE had problems talking over https.
Also wait for a bit (e.g. 30 minutes) after updating your domain records and
enabling kube-lego (i.e. just before this section:
[https://github.com/jetstack/kube-
lego/tree/master/examples/n...](https://github.com/jetstack/kube-
lego/tree/master/examples/nginx#enable-kube-lego) ).

------
clarry
The man page for acme-client shows how to automate renewal with cron. It is
quite simple.

[http://man.openbsd.org/OpenBSD-current/man1/acme-
client.1](http://man.openbsd.org/OpenBSD-current/man1/acme-client.1)

------
slavik81
I just remarked the other day that I haven't had an automatic renewal work yet
with tiny-acme. In theory, it should be ok, but for the first renewal the
intermediate certificate changed, requiring manual intervention. For the
second renewal, the Let's Encrypt terms of service changed, again requiring
manual intervention.

Alas, I don't really want to use the official client. It seems messy and
complex, and docker kind of contributes to that impression. I wish there was a
tool that was simple, clean and elegant.

~~~
pfg
FWIW, both of these issues are acme-tiny-specific quirks. The protocol allows
clients to handle both intermediate certificate changes and ToS updates
without any user interaction (and without breaking renewal). These things were
not implemented in acme-tiny in order to keep the LOC count low from what I
can tell.

I tend to recommend lego[1] to anyone needing a high-quality ACME client
without certbot's complex auto-configuration features. Might be what you're
looking for. It's written in go and can be installed by fetching a single
binary.

[1]: [https://github.com/xenolf/lego](https://github.com/xenolf/lego)

------
doublerebel
If you need a solution that works with your existing load-balancer/proxy/L7
router/nodejs server/microservice architecture, I built ten-ply-crest [0].
It's express middleware that is fully automatic to register new domains, when
used with Consul and an L7 router (Fabio, Traefik, Envoy, HAProxy) to route to
.well-known/.

Ten-ply-crest can run as a standalone microservice or on top of any existing
express app. It supports pluggable backends for storage, and doesn't rely on
the local filesystem.

It's really short on docs, but "release early and often!". It has been running
all my sites since the beginning of the year, Feel free to open issues with
any questions and I'll help you get running.

If you need a complete client lib for the LetsEncrypt API in JS, that's
included too [1].

[0]: [https://github.com/nextorigin/ten-ply-
crest](https://github.com/nextorigin/ten-ply-crest)

[1]: [https://github.com/nextorigin/ten-ply-
crest/blob/master/src/...](https://github.com/nextorigin/ten-ply-
crest/blob/master/src/models/letsencrypt.coffee)

------
rlpb
Let's Encrypt worked well for me the other day, except that I hit a firewall
problem. I firewall all "new connection" outbound traffic, so that if a web
app gets compromised, it can't start sending spam or try to spread a
compromise to other sites.

This caused Let's Encrypt to fail.

I worked around this by temporarily allowing outbound connections, but I
wonder whether this needs to be fixed more generally? It seems reasonable to
me to block all outbound connections on a web server that isn't expected to
need any. But Let's Encrypt's (perfectly reasonable) need to renew
certificates breaks this assumption. Unfortunately, it doesn't seem easy to
set up an exception on an IP-based firewall to allow Let's Encrypt outbound
connections only. This makes automated renewals hard.

~~~
mholt
Use the DNS challenge: no open ports or listeners on your machine, just set a
DNS record.

~~~
rlpb
No, it's the _outbound_ API connection that is the problem. The server listens
on HTTPS from the world, so having that listening inbound wasn't a problem.

~~~
ygjb-dupe
Right, so you can run the dns01 challenge on a separate service, up to and
including running it in jenkins to automatically renew and push your certs,
and kick the nginx server. I should document how my setup works and put it up
somewhere...

------
ex3ndr
I like automating via docker there are various docker images with haproxy or
nginx in it that automatically refresh certificates. Just install them as
reverse proxy for your frontend and here we are. Very useful and almost no
configuration needed.

------
jonotime
I love the Docker solution for this. Every day I find more and more problems
that Docker can solve for me.

However I dont think this will work for my setup. I run Arch Linux on a
Raspberry PI, which serves OwnCloud via Apache. I have always had to go the
manual route with lets encrypt because I dont run Debian.

The problem is these docker images are probably built with ubuntu or debian
and assume an intel architecture. So I would have to recreate these images for
arm - which means I would have to start with a different image.

Not hard to build myself, but I would basically need the original Dockerfile
and then recompile from there.

------
0xmohit
How To Secure Nginx with Let's Encrypt on Ubuntu 14.04 [0] also provides
details on how to use certbot to obtain SSL certificates.

[0] [https://www.digitalocean.com/community/tutorials/how-to-
secu...](https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-
with-let-s-encrypt-on-ubuntu-14-04)

------
eridius
> _Don 't sweat the permissions for this directory; the certificates
> themselves will not be publicly accessible._

Maybe still a good idea to sweat the permissions - the way it's set up right
now, any process on the system can _delete_ the certificates from this folder,
thus breaking your site until such time as you renew them.

------
Walkman
> "Are you wondering why I used 2:17 am? Well, there is a simple explanation
> for that: almost everybody else did not."

Reminds me of the "fair dice": [https://xkcd.com/221/](https://xkcd.com/221/)

~~~
mikeash
Seems like cron really should have a way to run a job at a random moment
between two points in time. I searched around some and all the solutions
involve terrible hacks like prefacing your command with /bin/sleep
$((RANDOM\%3600)).

~~~
digi_owl
Terrible hack, or building a solution from parts, i can't really tell the
diff.

~~~
mikeash
I think what turns it into "terrible hack" for me is the fact that it won't
properly handle the situation where the machine reboots after firing the cron
job and before the sleep completes. Having an extra process sitting around for
potentially hours doing nothing but waiting also seems ugly. Neither is
particularly _important_ though....

~~~
zzzcpan
Try scheduling a job with "at" in that crontab entry, some systems have it
installed by default and jobs persist across reboots. The at jobs are executed
through cron themselves.

~~~
mikeash
Good idea! I'll keep that in mind if I ever try to do it.

------
lpasselin
I'd really love to be able to use let's encrypt with gitlab pages. I know
there were people working on this but it still isn't available.

~~~
cmrx64
I use let's encrypt for gitlab pages, as seen here:
[https://robigalia.org/](https://robigalia.org/)

The key is doing a dns-01 challenge, instead of http-01, so you don't have to
put challenge-response garbage in your repo.

