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.
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.
> "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.
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.
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.
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.)
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.
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).
27 comments
[ 3.3 ms ] story [ 65.5 ms ] threadAn 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!
Not necessarily - GitHub pages serves up HTTPS so you can be HTTPS all the way down the line
But then you have to install and renew that cert on your origin.
Turtles all the way down.
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
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).
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.
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.
A reason not to use Caddy is significantly reduced performance as compared to Nginx.
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.)
https://certbot.eff.org/all-instructions/#ubuntu-16-10-yakke...
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.
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).
Well, not for nothing as I now know better.
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.