If you don’t already know LetsEncrypt! is an awesome project which aims to bring free HTTPS certificate to every site on the web. HTTPS makes everything safer and more secure by protecting your information and browsing history while it is in transit from your computer to the server. Traditionally, getting an HTTPS certificate was a confusing and expensive process. It was also something of a racket, as certificate providers rarely provided a technical service per-se, just a guarantee that they were keeping their certificates safe, and that your website’s certificate, which was based off of theirs, was also safe. HTTPS trust goes something like “I trust DigiCert.com, and DigiCert.com says that site.com is safe… so I guess I trust site.com!”

Anyway, you can read more about how LetsEncrypt! works on their site.

SwitchBoard.chat is a small web site I’m running (based on ActionHero of course) which allows your team to send and receive SMS messages to a centralize place, share messages and address books, and generally makes working with SMS for your team easier. As SwithBoard.chat is a small service right now, the front-end runs entirely on one server… and is a great candidate for a basic LetsEncrypt! HTTPS certificate.

You can read the SwitchBoard.chat launch announcement here.

The fine folks at the EFF have created CertBot, an easier-to-use wrapper around the LetsEncrypt! command line tools. Ansible is a tool which helps you configure your servers (and deploy to them) automatically. We can combine both of these to make automatic HTTPS certificate generation a breeze!

An aside about LetsEncrypt!: Unlike a normal certificate authority, who grants certificates for 1,2, or 3 years at a time, LetsEncrypt! *only* grants 3-month certificates. They do this because they *want* to encourage automation and re-generation of certificates. This encourages folks to constantly be proving that they really do own the domain in question, and leads to a safer internet for all of us.

For this setup, we are going to set up our front-end server like this:

First, ensure your DNS records are pointing to the server.

We now have a chicken-and-egg problem. We want to run NGINX to serve out site (and validations for LetsEncrypt!) but we don’t have our certs yet, son NGINX won’t boot. So the first time we run this, we need to run a temporary web server, but every subsequent time, we’ll use Nginx.

To generate those certs, here’s what we do:

The variables look like

Here are the steps broken out:

Install CertBot & dependancies (for Ubuntu/Debian)

Check if we are running the first time (no cert on system yet) or a subsequent time

Build our Install script.

Reload Nginx

How does this work?

If we are running the first time we are telling CertBot to spin up a temporary web server using the ` — standalone` flag. If we already have a running web server (NGINX) e are telling CertBot to use ActionHero’s public directory to place it’s trust files. What CertBot does is generate some custom files (which look like /.well_known/{{gibberish}}) and then tells the LetsEncrypt! server to try and load those generated URLs. If it can, it knows that you own the DNS addresses in question, and it grants you the certificate you asked for! CertBot can also run its own web server for the domain tests, but since we are already running NGINX, we don’t need to!

In our Ansible server provisioning step, we’ll then set up and run our ActionHero project. You should configure it listen only on a local socket, IE:

// from config/servers/web.conf exports.production = {

servers: {

web: function(api){

return {

port: '/home/deploy/www/switchboard.chat/shared/sockets/actionhero.sock',

bindIP: null,

padding: null,

metadataOptions: {

serverInformation: false,

requesterInformation: false

}

};

}

}

};

… and then you can configure NGINX to load your ActionHero project as a backend:

Our NGINX.conf (and the Ansible role to manage NGINX) looks like this:

You’ll notice that we are using `try_files` to attempt to have NGINX serve static files out of ActionHero’s public directory. While ActionHero can service static assets for you, NGINX is simply better and faster at it. This also allows NGINX to continue serving assets if the ActionHero server is down for some reason, and you can use JavaScript on in your front-end code to render an appropriate error message to your visitors if a health check fails.

NGINX is also sourcing our HTTPS certificates from a strange place… This is where CertBot will place our certs. That directory is actually a collection of Symlinks which CertBot will update as needed as it renews them for us.