Using Free SSL/TLS Certificates from Let’s Encrypt for Nginx | Hacker News Reader

Using Free SSL/TLS Certificates from Let’s Encrypt for Nginx

nginx.com

164 pointscujanovic49 comments

The official let's encrypt client is very heavy-weight. In my case I've build a much simpler thing using acmetool (https://github.com/hlandau/acme) which is mcuh simpler to use and nicely runs without root rights.

In my case, a lot of the routing of domains to customers is stored in a postgres database and a trigger fires an event anyways, so I have a little daemon that listens to these events and the fires off acmetool as needed in order go generate certificates.

I just completed this last week, so when I've seen this article here, I thought that I just wasted some time over this because now there's an integrated nginx solution, but thankfully, this is just an article about doing what I was doing using a tool that's more complicated to use and brings half of an OS installation as dependencies.

For those interested, https://gist.github.com/pilif/1e2610dd7aa57323e0b2 is the script in question. It's really a quick hack, but it works very well for me to auto-create nginx config files.

I'm the author of acmetool.

It's quite interesting to know that people are using the design to its full potential. Ideally, I should probably make something more library/daemon-based for these largescale, custom solutions, though of course I'd like to do it some manner of modular way that allows the existing codebase to be leveraged. For the time being only the acmeapi package within acmetool is stable and suitable for use by other libraries. Something to think about...

We should join forces with https://github.com/mholt/certs then. (Still in design phase.)

I've done some thinking on what makes sense and ended up at this very rough first sketch. Comments welcome.

https://gist.github.com/hlandau/ed6a96150c69945143be

For me, the current interface is perfect (though I wouldn't call our usage large-scale by a long shot), though it would be even better if acmetool would indicate using the exit code whether the web server needs restarting or not after reconciliation.

I know there are the hooks and that's what I'm using now, but if I could get a distinct exit code to tell me that changes happened to the certificate store, then I could get away without needing to also keeping the hooks around.

That said, this should probably be on your github issues, not in here. That also said: This was such a small issue for me that I didn't even want to bother you - but as you're coming here to post, I guess it doesn't hurt :p

I can't use the exit code, because a nonzero exit code by UNIX convention indicates failure, which will spam people in their cron jobs. There's only one exit code which conventionally means 'success'.

I could modify acmetool to output a word 'NEEDS-RELOADING' or something, which you could grep for programmatically. But this is another option (it would have to be an option; any output from acmetool is liable to get e. mailed to people via cron) for something which can be, as you yourself admit, dealt with as well via hooks. And probably more robustly, too. So on balance, I don't think it's worth doing.

I was hoping this was an nginx module where you could specify something like `ssl_letsencrypt on;` and be done with it.

Me too. I'm disappointed, this would be THE killer feature. Hope they are working on it (they should imho.)

Caddy has this feature and it's amazing. https://caddyserver.com/docs/automatic-https

Wow. I might check try it out then.

It really does do what it says it does.

https://github.com/Xe/dotfiles/tree/master/ansible/roles/cad...

https://xena.greedo.xeserv.us

I would definitely recommend it, I've replaced a few instances of nginx with it with no problems. It is based on the really solid net/http code from golang std lib and adds a few nice things like automatic tls/certs.

this is how it should work. Very nice. I can't wait for other web servers to gain this ability too. Or at least allow us to load certificates from dynamic locations based on some request data.

All other web servers I looked at (nginx, apache, lighttpd) still require at least a reload for an updated certificate and a configuration file change for a new certificate to be used.

I wonder how caddy works with the very low 5 certificates per public suffix and week limit. Does it automatically bundle domains and request a single certificate with SANs?

> this is how it should work. Very nice.

Yeah, Caddy is amazing. Matt is doing an awesome job with it.

> I wonder how caddy works with the very low 5 certificates per public suffix and week limit. Does it automatically bundle domains and request a single certificate with SANs?

I directed Matt to this discussion so I hope can answer these questions for you. I unfortunately cannot.

> this is how it should work. Very nice.

Thanks for your comments; glad you like the way we integrated it!

> Does it automatically bundle domains and request a single certificate with SANs?

No, as it turns out, SAN makes the auto-management code highly complicated, since names could overlap in different certs, etc. It also complicates renewals and gives more room for error (e.g. 49 of the domains verify but 1 fails, so the cert can't be renewed). So I've opted not to support SAN certificates for the automatic HTTPS feature. But you can of course still issue your own SAN certificates and use those.

Right now, Caddy reloads itself when it renews certificates, but as of Caddy 0.8.2 (slated for release any day now), Caddy will do it all in-process, no reloading.

From what I can see, Caddy also does a reload. With Apache, you can do a Graceful restart and not lose any traffic, plus, using mod_lua you could create a relatively easy way to add this automagically.

nginx you can also reload gracefully using the same mechanism. Still. It would be cool if it wasn't needed. I mean - you don't normally restart web servers when a file in the document root changes - why would you still have to do this for changes to SSL certs.

(note: I know that these are two very different things and I know how complicated it is to get all that state correct and to properly re-initialize the SSL context - still, as certificates get more and more short-lived, this would be a cool thing to have)

FWIW, Caddy's next version will be able to update the certs without reloading at all.

Caddy does graceful reload with zero downtime on Linux.

Know of an automated caddy docker reverse proxy container?

Here's an nginx one. Took about < 5 mins to add to my docker-compose file and start proxying my existing site

https://hub.docker.com/r/dmp1ce/nginx-proxy-letsencrypt/

Would love to see a caddy version of same

---

hmm, I guess the current caddy docker images can do this though though they need a little more configuration

There's ongoing discussion about this here: https://github.com/mholt/caddy/issues/199

One of my tasks this week is to get this in motion.

If you're open to using OpenResty (basically nginx with some additional plugins and Lua integration), I've coincidentally been working on a plugin to make all of this completely automatic with Let's Encrypt (taking advantage of the relatively new ssl_certificate_by_lua functionality OpenResty provides): https://github.com/GUI/lua-resty-auto-ssl We just rolled it out to our first production site last week, but any feedback would be welcome.

Or better yet, make "ssl_letsencrypt on;" the default. Make it so that newbies can just apt-get install nginx/apache/lighttpd/etc. and have https up and running, no questions asked. The real reason https adoption isn't up to par has less to do with people not willing to spend money, and more because it's not up by default. Now that https is free, please make it enabled by default.

Check out Caddy, which enables HTTPS by default: https://caddyserver.com/docs/automatic-https

That was something that I complained about even before letsencrypt. It's insanely difficult for anyone except crypto experts to figure out a sane selection of cipher suite, so why can't they not just include one or two sane presets with the application, that get updated along with it when algorithms are broken and new ones emerge?

I just went threw a full configuration and the cipther suit was the easiest. I had some guides and the basically said, copy this or this depending on how prohibitive you want it.

The hardest thing to figure out is HPKP (and I still have not).

are the guides up to date?

I used https://cipherli.st/

hopefully it's good, if not it isn't protecting anything important really

I think its not gona be easy as that - there has to be some croned process and some kind of error handling. (I created https://hub.docker.com/r/analogic/lemanager/ which does both but i am still waiting for some better "native" solution)

It could hypothetically be that easy, AFAICT. Nginx service runs constantly, so a module could presumably execute scheduled tasks. Those tasks could have error checking, sending errors to the root inbox.

I wrote up my own HOWTO for nginx just the other day.https://www.uhoreg.ca/blog/20160218-1757 I used the acme-tiny client instead of the official client. My post is mostly aimed at Debian-based distributions, but should be easily adaptable to others.

Has anyone found a good tutorial for DNS-based verification of a Let's Encrypt certificate? It'd simplify life greatly for those of us with multi-server clusters behind an Amazon ELB or something similar.

Not a tutorial, but I was having trouble with that damn 'official' Letsencrypt client and the complexity of adding a .wellknown directory on every site I needed a certificate for.

So I saw the light in the form of a bash-script [0], wrote a short hookscript, and now I can centrally manage through DNS.

There are a couple of example scripts [1], and it really simple to write your own.

[0] https://github.com/lukas2511/letsencrypt.sh

[1] https://github.com/lukas2511/letsencrypt.sh/wiki/Examples-fo...

If you don't mind renewing manually every 3 months, my manual client [1] does DNS.

https://github.com/veeti/manuale

Here is my Nginx config for let's encrypt on my case, feel free to criticize or copy it: https://gist.github.com/alex-min/158f35f604b24e163ae9. I've managed to get a A+ on the ssllab test so it should not be too bad I believe (but I'm not an expert so if you have some idea for improvements, I would be glad).

Here is my configuration: https://github.com/majewsky/system-configuration/blob/master...

Domains with this configuration get A+ on ssllabs and securityheaders.io (test with "repo.holocm.org" if you like). It includes an autorenewal script wrapped in a systemd timer unit.

There is one bug, though: The autorenewal script fails because letsencrypt crashes when stdin is not a TTY. ( https://github.com/letsencrypt/letsencrypt/issues/2523 )

You should also add HPKP (leaf pinning), it insanly powerful and a challange to get right. I have not figured out why the damn ssllabs complains about it to me.

I wanted to add it but I've seen all these warnings on the Internet about it and I'm not so sure I will be able to manage it if it does not work as expected. I've added X-Frame-Options, Strict-Transport-Security, X-Xss-Protection and X-Content-Type-Options because they have very few side-effects but I'm a bit afraid of HPKP.

I have the same problem, if I use one of the HPKP generators (or copy-paste a 'correct' example & substitute my cert hashes) I always get the SSL Labs error. Everything else is perfect. Depending on what guide I follow, I get Nginx errors, SSL Labs errors, or other third-party test errors. Never a consensus, which is what I would expect once everything is 100% correct.

I'll have to set aside a few more hours to figure this out soon. Even good documentation like this is not working for me: https://developer.mozilla.org/en-US/docs/Web/Security/Public...

How ironic. I just added https to my site and was searching for a solution to this problem. I ended up using certonly --standalone as described here and it worked like a charm: https://www.digitalocean.com/community/tutorials/how-to-secu...

I ended up still buying my certs because no solution seemed like something i should and could easily automate :/

I tried using the official encrypt client on my low spec VPS this weekend (cent os 6). It wouldn't install as when compiling it runs out of memory. Why so heavyweight. Luckily I found a python script which uses the acme tools stuff and that worked fine. Maybe providing binaries would be another option so I don't have to compile everything myself.

What were you compiling? The official client is written in Python.

The letscrypt auto thing.

Yeah, their documentation isn't very clear that auto actually compiles a bunch of stuff on the fly for you. I ran into the same issue as you with my low-spec VPS as well. You can either add some swap space, or run just "letsencrypt -certonly" and skip the auto junk, but it sounds like you did that with the acme client already. :) I've got an open issue on their github page to try and clarify the memory requirements for low-spec VPS..

Third party libraries used by the client require C extensions.

Thanks for the article and the other discusions, especially the pointers to Caddy.

I have been using Cloudflare for https for my main site only and have been deciding whether to use Cloudflare for everything or bite the bullet and set up my own https.

You should do both.

HTTPS from user to CF HTTPS from CF to your site

I've made an ansible role for deploying many sites from one nginx instance with automatic issuing and renewal of let's encrypt certificates.

It would be accompanied by a blog post to explain how things work but got busy on other fronts.

If anyone's interested, it's at https://github.com/Landoop/ansible

I had to add some extra nginx config to make this work ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';

Reply on news.ycombinator.com