Migrating a GitHub Pages blog with a custom domain to HTTPS06 Jul 2017
The only thing that has bugged me for a while now is that the whole site was served over HTTP, rather than HTTPS.
I wanted to move to move this blog to HTTPS, but with some constraints:
- Continue using GitHub pages (it’s free and easy, I don’t want to manage a server)
- No certificate renewal (smart me plans for stupid me, who would surely forget to renew a cert)
- Continue using my domain (mdjnewman.me)
- No cost
GitHub pages doesn’t support HTTPS for custom domain names, as it uses a
certificate with a wildcard SAN of
It looks like this will meet my constraints above - I get to keep using GitHub Pages, I don’t have to manage a cert (CloudFlare takes care of this), and I can keep using my custom domain.
The steps I followed to do this were relatively simple:
- Exported a zone file from current nameservers
- Completed the CloudFlare onboarding, during which I imported the above zone file
- Updated the authoritative DNS servers for my domain to the
- Tested the site out, fixed a CSS link that was loaded over HTTP
- Forced HTTPS in CloudFlare:
… and that was it. I finished this in part of an afternoon.
There is one major shortcoming with this setup: there is no certificate validation between CloudFlare and GitHub (CloudFlare supports fetching from an origin without validating certificates, which is the option I’ve chosen - ‘strict’ HTTPS can be enabled for most use cases).
As we mentioned before, the GitHub cert is valid for
*.github.io, and we’re
using my custom domain, which is
If we switched off the custom domain on GitHub, and did some smarts in
CloudFront to rewrite requests so that the request to GitHub was using
mdjnewman.github.io, then we’d get HTTPS all the way to GitHub servers.
CloudFlare does support rewriting HTTP Host headers , but it’s an enterprise feature.
I could switch to using CloudFront with an AWS Certificate Manager cert, which would meet all the above constraints except for ‘no cost’ (admittedly, my tiny blog doesn’t get much traffic, so the cost would be minimal).
Given that most of the shenanigans with injecting content into web sites happens at the last leg of a connection (I’m looking at you, dodgy internet cafe), I’m happy that the new setup for this blog mitigates that problem and am willing to accept the cost/security trade-off. While it’s possible for someone to perform a man in the middle attack and impersonate GitHub, given my site has no sensitive information I’m not too worried about this threat model (Troy Hunt also wrote about this trade-off).