I recently converted racecondition.software to HTTPS. This post discusses this change and will act as a smoke test, by which I mean that if this post doesn’t show up in my RSS reader, I will have more work to do.

The instructions I followed to use AWS S3 to host my website resulted in a website that was served via HTTP rather than HTTPS. This result caused two problems.

First, Google has publicly stated that HTTPS websites receive better treatment than HTTP websites in search rankings. One of the goals of racecondition.software is to reach as many readers as possible, and, given that Google search is a potential source of readers, HTTP was an impediment to reaching that goal.

Second, HTTP websites now bear stigmata of insecurity in various browsers.

I could not allow my precious website to suffer these stigmata.

Given these problems with HTTP, I decided to implement HTTPS. For reasons that are unclear to me, AWS requires use of its content-delivery network, CloudFront, to serve static websites via HTTPS. I spent a few hours with a support article and hit some roadblocks. I signed up for the lowest-tier AWS support plan and submitted a support request. To my delight, a fellow named Imran analyzed my request that evening and told me precisely what to do. I followed his instructions, and HTTPS appears to be working.

When I chose S3, I had no idea that using HTTPS would involve effort that seemed, at the time, Herculean. I don’t regret the choice of S3, but anyone considering S3 should be aware. Although Squarespace does not use HTTPS by default, their support article makes enabling HTTPS look easier than on S3. If HTTPS is a requirement for a new website, Squarespace and perhaps Wix may be easier options than S3. That said, the fast, inexpensive support I got from AWS mitigates this possible disadvantage.