9 ms·

Let's Automate Let's Encrypt

129 points by eth0up 10y ago

StavrosK 10y ago
All the Let's Encrypt automation I want to see is: sudo service nginx start And nginx gets/renews certificates automatically.
- jaas 10y ago
  That's where we'd like to see things go as well. Same for Apache. -Josh, head of Let's Encrypt
  - sandGorgon 10y ago
    isnt building an official lua script an option (like https://github.com/torhve/lua-resty-letsencrypt https://github.com/torhve/lua-resty-letsencrypt)
  - X86BSD 10y ago
    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.
  - atomi 10y ago
    Don't forget haproxy!
- vertex-four 10y ago
  Caddy, another web server, does this.
  - StavrosK 10y ago
    Yes, I use caddy extensively for non-production/internal and personal projects.
  - wanda 10y ago
    Wanted to point out the same. It's sort of marketed towards designers/less technical folk, but even to the seasoned developer it represents potentially less time faffing, and should be viable for at least for MVP or personal projects. Caddy is mostly just unproven at high scale; theoretically, nginx should be able to handle greater loads, but I wonder what Caddy's limits are and how big the difference would be. Haven't found time to benchmark them head-to-head.
  - Whitestrake 10y ago
    I'm using Caddy for almost all my personal projects, with the exception of those setups that are too complex to replicate in a Caddyfile. I think we're all just waiting for people to really test its performance under heavy loads and give it a chance to prove itself (or not).
- reustle 10y ago
  We've built a script like this internally, but would love to see it as an NGINX module :)
- ashark 10y ago
  While we're at it, can we make it that easy for Weechat relays?
- toomuchtodo 10y ago
  As long as nginx doesn't block on startup if it can't get the cert ;) "sudo service nginx certify" would be nice though.
  - mholt 10y ago
    What would you have it do instead?
    - jessaustin 10y ago
      Ideally there would be a cutover period. E.g. a month before the cert expires, attempt to renew on startup, and write a warning to log if that fails.
      - mholt 10y ago
        But what if it hasn't obtained a cert for the site before (e.g. first run)? What if the cert doesn't expire in a month -- but only, say, 7 days? 7 minutes? Where do you draw the line? Would you rather have your site go red in browsers or just not have the server start? (Remember, it wasn't started already anyway so it's not like your sites are incurring new downtime.)
        deleted 10y ago
        [deleted]
        jessaustin 10y ago
        Eh, the new run might be a failover, or part of an autoscaling setup, so maybe there could be some downtime? I think the default setting has to be to start anyway, although of course any particular service could be configured not to. Intentional failure seems kind of a blunt instrument?
        toomuchtodo 10y ago
        Thanks for communicating my thoughts on this in this thread far better than I. Spot on.
- zzzcpan 10y ago
  I'm pretty sure this only targets usage by small individual VPSs or something. For hosting services, especially with multiple nginx frontends, things are different.
- meirelles 10y ago
  It's complicated a one-fits-all solution. We ended using the S3 as storage back-end to provision, also to get a single cert for all frontend instances.
- 0xmohit 10y ago
  You don't need to restart nginx; reloading suffices. Moreover, it's good to test the configuration before restarting/reloading: nginx -t && sudo service nginx reload
- cguess 10y ago
  Here's a Dockerized version of NGINX that does just that: https://github.com/occrp/watchful-nginx https://github.com/occrp/watchful-nginx it also generates the dhparam file if there's isn't one and handles proper log rotations. disclosure: I work with OCCRP and have submitted pull requests on this.
clarry 10y ago
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
kozikow 10y ago
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/nginx https://github.com/jetstack/kube-lego/tree/master/examples/n... ), 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/nginx#enable-kube-lego https://github.com/jetstack/kube-lego/tree/master/examples/n... ).
Walkman 10y ago
> "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 10y ago
  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)).
  - rlpb 10y ago
    systemd can do this - see RandomizedDelaySec in systemd.timer(5). The hack you mention for cron doesn't seem particularly bad though.
  - digi_owl 10y ago
    Terrible hack, or building a solution from parts, i can't really tell the diff.
    - mikeash 10y ago
      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 10y ago
        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.
        10y ago
ex3ndr 10y ago
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.
warcode 10y ago
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.
- fideloper 10y ago
  same here. i have a video/article on it (single page, no docker thrown in because whatever "not-so-well-sandboxed third-party code on your server" means): https://serversforhackers.com/video/letsencrypt-for-free-easy-ssl-certificates https://serversforhackers.com/video/letsencrypt-for-free-eas... (sidenote: Would be interested to hear if there's actually any security issues with putting the certbot client on your machine)
- grawlinson 10y ago
  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. :)
- jaimex2 10y ago
  How do people not know this? It's literally the frist thing they tell you in the get started section of LE
lpasselin 10y ago
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 10y ago
  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.
zokier 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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.
doublerebel 10y ago
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/models/letsencrypt.coffee https://github.com/nextorigin/ten-ply-crest/blob/master/src/...
rlpb 10y ago
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 10y ago
  Use the DNS challenge: no open ports or listeners on your machine, just set a DNS record.
  - rlpb 10y ago
    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 10y ago
      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...
- q3k 10y ago
  If you're using a local iptables ruleset as your firewall, you can use the owner module [1] to filter by UID/GID, for example allow establishing connections from the user that runs your LE automation. [1] - https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#OWNERMATCH https://www.frozentux.net/iptables-tutorial/iptables-tutoria...
- 10y ago
slavik81 10y ago
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 10y ago
  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
0xmohit 10y ago
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-secure-nginx-with-let-s-encrypt-on-ubuntu-14-04 https://www.digitalocean.com/community/tutorials/how-to-secu...
misiti3780 10y ago
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 ?
- dingaling 10y ago
  > why is anyone purchases certs anymore ? 0. The cost of certificates is pretty insignificant to most corps. 1. They like to have someone to shout at when cert issuance fails. They happily pay money for this ( see point 0 ). 2. LE's cert renewal policies aren't compatible with most corporate change-management processes. Having someone assigned to perform rolling cert changes every 60 days on every server just isn't feasible or desirable. When I worked at "Fortune 50 Corp", an annual ( or even biannual / triannual ) planned cert update was a big deal and we had to stage the change across groups of servers in accordance with an algorithm that ensured that if they all inadvertently screwed-up that there enough servers with the old certs to keep production and pre-pro running. 3. Customers, particularly of financial insitutions, like to see the reassuring green EV indicator in their browser.
- rabbitfang48 10y ago
  > 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/
  - misiti3780 10y ago
    interesting - thanks!
thaumaturgy 10y ago
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.
jonotime 10y ago
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.
eridius 10y ago
> 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.

129 points by eth0up 10y ago

All the Let's Encrypt automation I want to see is: sudo service nginx start And nginx gets/renews certificates automatically.

jaas 10y ago
That's where we'd like to see things go as well. Same for Apache. -Josh, head of Let's Encrypt
- sandGorgon 10y ago
  isnt building an official lua script an option (like https://github.com/torhve/lua-resty-letsencrypt https://github.com/torhve/lua-resty-letsencrypt)
- X86BSD 10y ago
  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.
- atomi 10y ago
  Don't forget haproxy!
vertex-four 10y ago
Caddy, another web server, does this.
- StavrosK 10y ago
  Yes, I use caddy extensively for non-production/internal and personal projects.
- wanda 10y ago
  Wanted to point out the same. It's sort of marketed towards designers/less technical folk, but even to the seasoned developer it represents potentially less time faffing, and should be viable for at least for MVP or personal projects. Caddy is mostly just unproven at high scale; theoretically, nginx should be able to handle greater loads, but I wonder what Caddy's limits are and how big the difference would be. Haven't found time to benchmark them head-to-head.
- Whitestrake 10y ago
  I'm using Caddy for almost all my personal projects, with the exception of those setups that are too complex to replicate in a Caddyfile. I think we're all just waiting for people to really test its performance under heavy loads and give it a chance to prove itself (or not).
reustle 10y ago
We've built a script like this internally, but would love to see it as an NGINX module :)
ashark 10y ago
While we're at it, can we make it that easy for Weechat relays?
toomuchtodo 10y ago
As long as nginx doesn't block on startup if it can't get the cert ;) "sudo service nginx certify" would be nice though.
- mholt 10y ago
  What would you have it do instead?
  - jessaustin 10y ago
    Ideally there would be a cutover period. E.g. a month before the cert expires, attempt to renew on startup, and write a warning to log if that fails.
    - mholt 10y ago
      But what if it hasn't obtained a cert for the site before (e.g. first run)? What if the cert doesn't expire in a month -- but only, say, 7 days? 7 minutes? Where do you draw the line? Would you rather have your site go red in browsers or just not have the server start? (Remember, it wasn't started already anyway so it's not like your sites are incurring new downtime.)
      - deleted 10y ago
        [deleted]
      - jessaustin 10y ago
        Eh, the new run might be a failover, or part of an autoscaling setup, so maybe there could be some downtime? I think the default setting has to be to start anyway, although of course any particular service could be configured not to. Intentional failure seems kind of a blunt instrument?
        toomuchtodo 10y ago
        Thanks for communicating my thoughts on this in this thread far better than I. Spot on.
zzzcpan 10y ago
I'm pretty sure this only targets usage by small individual VPSs or something. For hosting services, especially with multiple nginx frontends, things are different.
meirelles 10y ago
It's complicated a one-fits-all solution. We ended using the S3 as storage back-end to provision, also to get a single cert for all frontend instances.
0xmohit 10y ago
You don't need to restart nginx; reloading suffices. Moreover, it's good to test the configuration before restarting/reloading: nginx -t && sudo service nginx reload
cguess 10y ago
Here's a Dockerized version of NGINX that does just that: https://github.com/occrp/watchful-nginx https://github.com/occrp/watchful-nginx it also generates the dhparam file if there's isn't one and handles proper log rotations. disclosure: I work with OCCRP and have submitted pull requests on this.

clarry 10y ago

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

kozikow 10y ago

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/nginx https://github.com/jetstack/kube-lego/tree/master/examples/n... ), 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/nginx#enable-kube-lego https://github.com/jetstack/kube-lego/tree/master/examples/n... ).

Walkman 10y ago

> "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 10y ago
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)).
- rlpb 10y ago
  systemd can do this - see RandomizedDelaySec in systemd.timer(5). The hack you mention for cron doesn't seem particularly bad though.
- digi_owl 10y ago
  Terrible hack, or building a solution from parts, i can't really tell the diff.
  - mikeash 10y ago
    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 10y ago
      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.
      - 10y ago

ex3ndr 10y ago

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.

warcode 10y ago

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.

fideloper 10y ago
same here. i have a video/article on it (single page, no docker thrown in because whatever "not-so-well-sandboxed third-party code on your server" means): https://serversforhackers.com/video/letsencrypt-for-free-easy-ssl-certificates https://serversforhackers.com/video/letsencrypt-for-free-eas... (sidenote: Would be interested to hear if there's actually any security issues with putting the certbot client on your machine)
grawlinson 10y ago
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. :)
jaimex2 10y ago
How do people not know this? It's literally the frist thing they tell you in the get started section of LE

lpasselin 10y ago

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 10y ago
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.

zokier 10y ago

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 10y ago
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 10y ago
  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 10y ago
    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.

doublerebel 10y ago

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/models/letsencrypt.coffee https://github.com/nextorigin/ten-ply-crest/blob/master/src/...

rlpb 10y ago

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 10y ago
Use the DNS challenge: no open ports or listeners on your machine, just set a DNS record.
- rlpb 10y ago
  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 10y ago
    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...
q3k 10y ago
If you're using a local iptables ruleset as your firewall, you can use the owner module [1] to filter by UID/GID, for example allow establishing connections from the user that runs your LE automation. [1] - https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#OWNERMATCH https://www.frozentux.net/iptables-tutorial/iptables-tutoria...
10y ago

slavik81 10y ago

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 10y ago
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

0xmohit 10y ago

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-secure-nginx-with-let-s-encrypt-on-ubuntu-14-04 https://www.digitalocean.com/community/tutorials/how-to-secu...

misiti3780 10y ago

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 ?

dingaling 10y ago
> why is anyone purchases certs anymore ? 0. The cost of certificates is pretty insignificant to most corps. 1. They like to have someone to shout at when cert issuance fails. They happily pay money for this ( see point 0 ). 2. LE's cert renewal policies aren't compatible with most corporate change-management processes. Having someone assigned to perform rolling cert changes every 60 days on every server just isn't feasible or desirable. When I worked at "Fortune 50 Corp", an annual ( or even biannual / triannual ) planned cert update was a big deal and we had to stage the change across groups of servers in accordance with an algorithm that ensured that if they all inadvertently screwed-up that there enough servers with the old certs to keep production and pre-pro running. 3. Customers, particularly of financial insitutions, like to see the reassuring green EV indicator in their browser.
rabbitfang48 10y ago
> 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/
- misiti3780 10y ago
  interesting - thanks!

thaumaturgy 10y ago

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.

jonotime 10y ago

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.

eridius 10y ago

> 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.