Using Caddy to HTTPS all the things04 Apr 2017
Caddy is a lightweight web server that amongst it’s features, has integration with LetsEncrypt to automatically request certificates. This means that you now have absolutely no excuse anymore to run your apps over plain old HTTP anymore. Let me be clearer. If you are running web services over HTTP, regardless of whether it touches the internet or not, you are doing it wrong.
- A t2.micro Ubuntu 16.04 instance with 20 GB of storage attached (probably excessive for this demo setup).
- Assigned an Elastic IP to the instance (so it has an external IP)
- Created an A record in DNS that points to the elastic IP (needed for LetsEncrypt)
- Allowed SSH, HTTP and HTTPS into the instance via the security group
The setup of the above is out of the scope of this post, but it should be easily google-able.
We are going to run all of this in Docker containers. SSH into the server and:
Let’s get Caddy up and running. There’s a decent image already that makes it pretty easy to stand up a web server. First off we’re just going to pull the image and serve the default site over HTTP.
And if you hit you server’s hostname (e.g. example.yourdomain.com), you will now see the default page for your Caddy server.
That’s all well and good, but using the default configuration isn’t very useful. Put the following into a file called
Caddyfile. Once again, replace
example.yourdomain.com with the actual hostname that points to your server.
And let’s kill our old container and start up a new one:
So we have what we had before. How do we configure Caddy to serve HTTPS? We don’t need to do anything, we just need to hook up port
443 in our container to the outside world.
And then reload your page in your browser.
OMG IT’S HTTPS WITHOUT DOING ANYTHING!
So let’s make this do something useful. We are going to make use of Caddy’s ability to be a reverse proxy so that it can sit in front of our Sal container and provide easy HTTPS. First off we’re going to stand up a normal Sal install - notice we do not expose any of Sal’s ports to the outside.
Now your database has started (you can
sudo docker logs db to make sure), it’s time for our Sal container.
As soon as
sudo docker logs sal says that gunicorn is running, we’re ready to expose it to the internet. We are going to make use of a feature in Docker where we automagically get access to the other containers it is linked to (in this case, we are going to hit http://sal:8000). Open up your
Caddyfile and make it look like the following:
And finally we can start up our proxy container:
And like magic…
Doing this will re-request new certificates from LetsEncrypt every time the container is removed and recreated. If you do this often enough, you will hit their rate limit, so let’s make sure we keep the certificates by linking the right directory in our container to the host machine.
So that is how you can run any app behind HTTPS for free. No go and get everything encrypted. No excuses. I don’t want to see any more installations of Sal or Crypt running unencrypted. Please - or I may cry.