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.
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?
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.
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)
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.
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).
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.
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.
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...
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.
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.
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).
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.
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 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.
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..
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.
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';
49 comments
[ 2.2 ms ] story [ 62.6 ms ] threadhttps://github.com/Xe/dotfiles/tree/master/ansible/roles/cad...
https://xena.greedo.xeserv.us
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?
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.
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.
(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)
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
One of my tasks this week is to get this in motion.
The hardest thing to figure out is HPKP (and I still have not).
I used https://cipherli.st/
hopefully it's good, if not it isn't protecting anything important really
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.
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...
https://gist.github.com/hlandau/ed6a96150c69945143be
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 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.
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...
https://github.com/veeti/manuale
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 )
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...
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.
HTTPS from user to CF HTTPS from CF to your site
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