Adding SSL to this Blog

Posted July 2017

Because this is a basic static site I've not previously bothered with SSL. But as Chrome and Firefox will require HTTP/2 requests to be encrypted, and with Chrome marking HTTP as non-secure, I figure it's time to do something about that.

Since writing this post series I changed the domain of this site from superloopy.io back to brautaset.org.

GitHub Pages, where this site is currently hosted, regretfully doesn't support HTTPS for custom domains. (It does, however, support it for $username.github.io domains.) At work I was recently pleasantly surprised how convenient Amazon Certificate Manager & CloudFront is for obtaining & deploying certificates, and I thought I would use that for this project. I also want to do this with CloudFormation, so I have a repeatable setup at the end. (I have a couple other sites that can benefit from SSL too.)

For hosting the content there's a couple different approaches I could take:

  1. Continuing to publish static HTML to stig.github.io and use that as the Origin
  2. Publish static HTML to S3 and use that as the Origin

Since I no longer use Jekyll but check in generated files, switching to publishing them to S3 instead is my preferred option.

There is an additional issue to solve. I want the Apex domain (i.e. superloopy.io) redirecting to www.superloopy.io. This is currently handled by GitHub, but I would like to use S3 to handle this redirection, as outlined in Hosting a Static Website on Amazon S3. However, you cannot CNAME the Apex domain to an S3 bucket—as required by that approach—unless you rely on Amazon Route 53 for your DNS needs. So the first part of this project will probably be to delegate1 my DNS to Route 53.

Thus, a plan emerges:

  1. Manage DNS for superloopy.io with AWS Route 53
  2. Handle redirects from Apex domain to www with an S3 bucket
  3. Create an S3 site bucket, fronted by ACM-provided SSL Cert via CloudFront, that I can publish by blog from2
  4. Change my blog publishing setup to populate the S3 bucket from previous step2
  5. Update DNS using Fn::ImportValue in CloudFormation3

One thing I have in abundant supply is lack of time, so I'm afraid those steps will have to be the subject of future posts.

1

I don't want to transfer the actual domain, at least yet, as I've been happy with Gandi for many years and they are a bit cheaper than AWS for .io domains.

2

I changed the order of steps 3 and 4 as I came to realise I have to actually have an S3 bucket to publish to in order to test the change to publishing.

3

I forgot to update my DNS stack when creating the S3 buckets, as I had intended, so I do it as a separate step.