
How to secure your website with Nginx and Let's Encrypt - shir0kamii
https://blog.shir0.fr/2018/01/nginx-letsencrypt-en
======
eridius
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](https://caddyserver.com)

~~~
Xeoncross
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](https://github.com/mholt/caddy#install)
version for commercial projects (Apache 2.0).

~~~
mholt
> "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.

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

[https://certbot.eff.org/all-
instructions/#ubuntu-16-10-yakke...](https://certbot.eff.org/all-
instructions/#ubuntu-16-10-yakkety-nginx)

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

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

~~~
schoen
> 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).

~~~
rconti
Thanks, that makes sense.

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

------
krono
Automated with Docker, [https://github.com/jwilder/nginx-
proxy](https://github.com/jwilder/nginx-proxy) and
[https://github.com/JrCs/docker-letsencrypt-nginx-proxy-
compa...](https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion)

------
naggie
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](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/](https://www.ssllabs.com/ssltest/) .

Hopefully it's useful to someone.

------
chrisparton1991
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!

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

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

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

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

