How to secure your website with Nginx and Let's Encrypt | Hacker News Reader

How to secure your website with Nginx and Let's Encrypt

blog.shir0.fr

48 pointsshir0kamii27 comments

If you're looking to get a simple server up and running that supports Let's Encrypt, it's a lot easier to use Caddy¹ than it is to set up Nginx with LE. Out of the box Caddy will automatically secure all your sites with LE (and automatically redirect http to https), and it also makes a lot of other common configurations much simpler than Nginx does.

Of course, there are still plenty of reasons to use Nginx, so documentation like this is great. But speaking as someone who had Nginx with LE set up and migrated over to Caddy some months ago, it's a lot simpler to manage my server (and especially set up new virtual hosts) now.

¹https://caddyserver.com

The hard-sell when I first looked at caddy scared me away. "Non-commercial use only" isn't the kind of server I want to have as a default.

Update: Looks like you can skip the marketing site and use the https://github.com/mholt/caddy#install version for commercial projects (Apache 2.0).

> "Non-commercial use only" isn't the kind of server I want to have as a default.

You mean, for free. (I'm not sure why businesses would expect that their critical software be free?) We sell commercial licenses of the binaries that of course allow commercial use. Or you can, as you said, build from source if you prefer to do that. The source code is Apache-licensed.

What about Caddy made it easier? It's very simple to set up a basic Nginx site and run certbot... like 'under 5 minutes' simple.

Caddy does it all without needing an external dependency or crontab or custom configuration to handle the HTTP challenge. Caddy config files also just end up being simpler in general. When I moved from Nginx to Caddy my vhost files ended up at least 50% smaller, if not more, and with a lot less repetition.

Note that when you create a new vhost in Caddy it automatically gets LE support. No need to update your crontab to pass the new domain to certbot.

Certbot manages its own cronjobs, same with changing the config to handle the HTTP challenge.

A reason not to use Caddy is significantly reduced performance as compared to Nginx.

Sure, if you’re at the point where the performance of Caddy is a limitation, by all means switch to Nginx. My sites aren’t even close to that limit though, and it’s a lot simpler to start out with Caddy. No sense in doing unnecessary work before you need to.

There isn't a hard limit (that I know of), you're just consuming more resources for each page load and likely doing it slower than nginx would.

By the same argument you should never use node.js or ruby or python or whatnot to write your app and should always use something like C++ or Rust.

If you consider creating a ~10 line site config in nginx equivalent to developing an entire application in Rust... sure?

Caddy didn't break when Let's Encrypt disabled the TLS-SNI challenge. Many other ACME clients (even Certbot) did. Also, having a fully-integrated solution will be more reliable and lower-maintenance, especially in the long run.

And Caddy's faster than you think -- "significantly reduced performance" is an overgeneralization. Caddy may happily serve tens of thousands of requests per second. (It all depends on, well, a lot of things.)

It's even easier to just have certbot install and configure everything for you.

https://certbot.eff.org/all-instructions/#ubuntu-16-10-yakke...

Neat, thanks. This is exactly the workaround I was looking for but didn't search hard enough to find.

Sounds like they're working on a new http challenge plugin for nginx that should solve this webroot hack/workaround for the fact that the existing nginx plugin for certbot only works over tls-sni-01 which has been disabled by the letsencrypt folks.

I anxiously await it as it's easier to deal with the nginx plugin when you've already got nginx running for other reasons, rather than having to disable your existing webserver.

Not thrilled about having to temporarily allow http, but c'est la vie.

I wonder why we can't just have an https-based known-file challenge that works exactly like the http one, but over https, and just accepts whatever cert you throw at it initially.

> I wonder why we can't just have an https-based known-file challenge that works exactly like the http one, but over https, and just accepts whatever cert you throw at it initially.

This method was called HTTPS-01 and was initially discussed at the IETF ACME WG. My recollection is that it was rejected for a reason similar to why TLS-SNI-01 has just been disabled: many hosting providers' practices would designate one customer as the default HTTPS virtual host for all incoming HTTPS requests. Therefore, that customer would be in a position to get a certificate for any other customer on that infrastructure. This problem was easier to notice for HTTPS-01 than the corresponding problem with TLS-SNI-01 (which is that you can upload invalid certificates for names that aren't hosted on the infrastructure at all, and thereby get some shared hosting environments to believe that they're third-party certificates for your own sites that you've imported from elsewhere, while they're actually ACME challenge certificates for a different customer on the same infrastructure).

Thanks, that makes sense.

You mean I spent last weekend learning how to update my DNS with nsupdate to replace the nginx sni broken challenge for nothing :-D ?

Well, not for nothing as I now know better.

If you want the easy way but you are not using certbot you are doing it (quite possibly, you know, given the requirements, but your milage my vary anyway so oh wait this is becoming a disclaimer or what) wrong.

Automated with Docker, https://github.com/jwilder/nginx-proxy and https://github.com/JrCs/docker-letsencrypt-nginx-proxy-compa...

I automated this and other standard nginx configurations with ansible for ubuntu 16.04. Here's the role: https://github.com/naggie/nginx-https-base

It uses webroot + certbot for zero downtime deployment, and provides neater error pages. Also gets an A+ on https://www.ssllabs.com/ssltest/ .

Hopefully it's useful to someone.

This is a nice, concise guide. I use LetsEncrypt for one of my sites running on a DigitalOcean box, they have some excellent documentation there as well.

An alternative to LetsEncrypt is to sign up for Cloudflare's free tier. You get free SSL (using their shared certificate) and a bunch of other goodies. I have a couple of sites hosted on GitHub Pages using Cloudflare, so I have SSL and hosting at zero cost. Hard to beat that price!

The problem with that is that the connection from CloudFlare to your server is unencrypted. Ideally you will still have SSL implemented on your own server/network even when using a CDN provides it for the public facing domain.

Yep, agreed. I only use Cloudflare's SSL for a couple of static landing page websites. For things like that, I think Cloudflare is perfect. For anything else, I use LetsEncrypt.

> The problem with that is that the connection from CloudFlare to your server is unencrypted.

Not necessarily - GitHub pages serves up HTTPS so you can be HTTPS all the way down the line

Cloudflare will issue you a cert from their internal CA so the POP-origin connection can be secured.

But then you have to install and renew that cert on your origin.

Turtles all the way down.

Why not `certbot renew` for renewing certs and pace the cron job every 7 days or so ?

I didn't look into that command but will be looking soon, thanks for the tip!

Reply on news.ycombinator.com