Finishing off the padlock

I had switched over to https by getting a certificate, but there was still one more piece of the puzzle

I while back I wrote about getting my site set up for https by purchasing a certificate and running nginx to proxy connections to the underlying application. The one issue I still had left was the fact that I was playing around with Amazon's Cloudfront service for serving all the media for the my site (not that there is much). The way I set up my distribution was to refer to the Cloudfront distribution hosts as and all media assets are served from there. They are backed by an Amazon S3 bucket to which I upload the media. Since I purchased a single domain certificate from Comodo, that pretty much only ensures that connections to and are legitimate.

As stated in the article I wrote in September, if you go to one of my blog posts with media, Chrome warns you that although the connection is secure, "attackers" could alter what it looks like. This is because the certificate doesn't guarantee that your connections to are really connecting to the hosts they appear to. Therefore it would be possible for someone to "man in the middle" the media and change them to other content.

I told myself that "some day" I'd get around to addressing that. The other day I was informed by Amazon that my chosen distro, Ubuntu 12.04 instance with a fresh version of Ubuntu, rather than upgrading migrating my existing instance. I only have one or two things running on the old instance, and, so I wanted to see how easy it would be to just start fresh.

After getting the handful of packages installed and getting the site up and running, it was time to look into the certificate issue. It seems like there are a couple of choices:

  1. Purchase a wildcard certificate capable of ensuring that connections to,, etc. are valid
  2. Keep the existing certificate and alter the Cloudfront distribution's alternate domain name (CNAME) to

Of course there's also the options to do nothing and don't worry about it. I don't do any e-commerce or serve any content that really needs a secure connection, so really all https is doing for me right now is giving me a chance to learn about it, and protecting my log in details should I decide to update my blog while on a network other than my home network.

I ended up purchasing a new certificate, one that supports wildcard subdomains. There is something you should be aware of when using a service like Cloudfront. You'll have to upload your certificate, the CA chain, AND the server's private key (the one you had to generate to sign the certificate for the CA) to Amazon. There's just no way around it since the server's private key is used to create the signature needed to verify it's authenticity. This is not unique to Amazon and Cloudfront, other edge services would need this too, for example Cloudflare the edge service often used to protect against DDoS attacks, would have you go through the same process of distributing your key as well.

I don't quite understand why the single domain certificate costs US$9.99 per year and the wildcard certificate costs US$94.99 per year, but perhaps someone out there will enlighten me. It's seems to me that it is the same logic. You either validate that two host.domain names match a list or that N host.domain names match an expression. I started to look at Let's Encrypt, but since their certificates a purposely set up to expire every 90 days, I would have had to manually renew or set up automatic renewal with cron or something. Maybe I'll do that for in order to see if I really need a wildcard cert or if you can just set the Cloudfront distribution's CNAME to the same as your domain name.