SSL for Everything Else

Last post I mentioned how easy it was to setup SSL with AWS Certificate Manager.

But what about all your other servers? Are we going to cough up $16 per year for a single-domain SSL certificate from Gandi?


Let’s talk about Let’s Encrypt. I downloaded their Linux version and got down to business.

Here is a running tally of my steps.

  1. Google “nginx letsencrypt” and find this DigitalOcean guide.
  2. Stop my nginx server to free up port 80, which is used in the letsencrypt process.
  3. run $ ./letsencrypt-auto certonly –standalone
  4. Enter my domain name.
  5. Make 15 seconds worth of changes to my server blocks in nginx.
    1. Redirect port 80 -> 443
    2. Setup a block for port 443 SSL, all in the guide
  6. $ sudo service nginx start

It took 5 minutes to fully setup.

I love it when life is stupid easy.


Easy SSL with AWS Certificate Manager

Amazon Web Services recently rolled out the AWS Certificate Manager: blog post

Always a brave soul, I used it to set up HTTPS for a domain name I have lying around. I’m writing about how it blew me away. It’s so damn easy.

I’m a big fan of HTTPS. Being a security enthusiast (note: not qualified expert) I think the whole protocol is pretty sexy.

Michael’s Old Dumb Way

Normally, I use the one-year free SSL certs from gandi. Free is always good, but setting it up is a pain in the ass. For each domain name I need to fill out the form for a Certificate Signing Request, etc.

Then I need to configure my web servers to use HTTPS, usually by updating my nginx configuration.

The AWS Way – Best Way

This process can be completed in 30 minutes or less, especially if you’re familiar with AWS.

Step 1: Route53

Create a hosted zone with your domain name ( Go to your registrar and input Amazon’s nameservers.

Step 2: Amazon Certificate Manager

Create a certificate request for Amazon will send you a confirmation request via your WHOIS contact email. Accept it and boom you’re done!

Step 3: Elastic Load Balancer

Create a load balancer instance that accepts both http (80) and https (443) in it’s security group configuration. Attach your ec2 instances to the load balancer.

Note: It’s good practice to make sure your ec2 instances only accept traffic coming from your load balancer’s security group. I allowed public ssh for convenience.

If you use the default health check (, this will get your ec2 instance up and running quickly.

$ ssh -i yourkey.pem ubuntu@ec2-blahblahblah
$ echo "Hello World!" >> index.html
$ sudo python -m SimpleHTTPServer 80

Go to the AWS Certificate Manager interface and create a new record set. Click “yes” for alias and select your Elastic Load Balancer instance by clicking on the blank.

Congratulations! Visit and bask in the glory.

Or visit in the next hour to see my Hello World!.


Chroot Jail Part 3

Recently I decided my dev DigitalOcean instance needed a boost. Normally 512mb is sufficient for production but I want to develop remotely.

I opted for a temporary resize to 1gb of RAM.

I also learned that my attempts to bind /dev/urandom and /dev/tty in /etc/fstab were failing miserably. I had to use DigitalOcean’s VNC connection and manually try to figure things out.

Remember how often I hit Ctrl-W and closed the tab still raises my blood pressure.

I ended up using /etc/rc.local to run


$ sudo mount --bind /dev/urandom /jailthing/urandom
$ sudo mount --bind /dev/tty /jailthing/tty

And it worked like a charm!

No more VNC to setup my convoluted login scheme anymore!

Getting MEAN

I’m forcing myself to build websites to back my domain names. If you didn’t know this about me, I love buying domain names. Sadly, I’ve been lax about making use of them.

Beautiful names like and are wasted.

Well actually is set up with No-Ip to give my personal machines subdomains, but that service has proven less than useful to me.

To get back into the web space, I chose to play with MEAN.

I head on over to the tutorial page and get cracking. My target server is a 512mb Digital Ocean droplet with Ubuntu 14.04.

Everything goes smoothly for the most part. I did hit a few snags:

mean init

This command initializes your application. It creates a directory of your choosing with a skeleton app.

If for any reason this fails (root owns ~/.npm, oops), the directory is still created. Simply running mean init again errors out due to the directory already existing. I had to rm -rf that shit and it’s annoying.

The tool offers to set up an admin user but requires a password of either letters, numbers or dashes with max length 15. What the hell.

npm install

The process is killed if the process requires more memory than is available. No error message beyond “Killed” is emitted. This step will fail on a 512mb instance.

The accepted workaround is to either create or expand the swapfile used by the system.


I’ll make another post about my actual development experiences, stay tuned!




Micro Utilities

Recently I’ve created a tiny site called It’s a repository for all the small utilities I write from now on.

On that note, I thought about the API that these little utilities should expose.

Most bash scripts or utilities use command line arguments to define behavior. This is great for humans but can be a pain when calling scripts from other scripts.

My current strategy is to implement the same API in all scripts:


Debug output -> STDERR


All options, flags and input data are encompassed in the input JSON. Likewise, all output is exposed as JSON. Human-readable output is sent to STDERR.

We’ll see if this utility convention works out!