In the first article on this site, I described a way to host your site or blog on GitHub Pages while having it accessible via your own domain. I left the article with one thing left unsolved: the site was not accessible via HTTPS, and something like that would not fly in the current year. Let us see how one can fix that – for free.
While GitHub Pages issues a free SSL certificate for you if you access your site via the
github.io domain, it unfortunately cannot (yet?) generate a certificate for your custom domain. Well, worry not, this is easily solvable by using Cloudflare (also known as Buttflare to the users of the extremely useful Cloud to Butt Chrome extension 🍑).
Cloudflare is many things: it’s a cache, a content delivery network, a DNS provider, it saves you traffic by compressing and minifying your site, it protects your site from DDoS attacks and content scraping, modifies your site on the fly with Cloudflare applications and it even prepares the coffee in the morning for you ☕. Also, I might be lying about the last one 🤥.
Anyhow, without further ado, here’s how I did it for my site.
Setting up Cloudflare
Like any proper IT fairytale, it all started with registering a new account with Cloudflare. After you’re done with that, you’ll be taken to a configuration wizard that will lead you through the steps necessary for Cloudflare to start taking care of your domain.
Once you fill in your domain name, your existing DNS records will be analysed and transferred over to Cloudflare. I’d recommend paying careful attention during this step as Cloudflare’s auto-detection does fairly good, yet not perfect job.
In my case, Cloudflare was able to find apex domain’s
A record, apex domain’s and
CNAME records, all
MX records and apex domain’s
TXT records. Everything else you’ll have to configure manually; I recommend going through your old DNS records, which you can likely find in your domain registrar’s administration interface, and transferring them one by one over. Vivaldi’s split screen view is absolutely amazing for this.
After you’re done, Cloudflare will assign you two name-servers (these are different for each domain so I can’t just write the addresses of my name-servers here for you) and with the knowledge of these addresses, you’ll have to go back to your domain’s registrar’s administration interface and configure Cloudflare’s name-servers as your domain’s primary and secondary name-servers. As far as I can tell, Cloudflare (or for that matter, anyone else) doesn’t really care about which one of them is primary and which one is secondary.
Once Cloudflare is successfully set up for your domain, you can head to their administration panel, into the Crypto section, and verify that the SSL option is set to Full. You may also want to scroll down and turn Always use HTTPS to On, Automatic HTTPS Rewrites to On and if you care about your site’s SSL Labs rating, you may want to go through the configuration of the HTTP Strict Transport Security (HSTS) option; however, be incredibly careful with the last one, read through all the warnings Cloudflare shows you and verify that Cloudflare already issued a SSL certificate for your domain (issuing may take a few minutes, and after all, you just signed up for the service – so if the certificate is not ready yet, just be patient and return in a while 🐊) and that HTTPS is working correctly for your domain. I recommend first verifying that everything truly works, waiting a few days during which you test just HTTPS alone and if everything seems fine and dandy, go for the HSTS option. In order to score an A+ grade on the test, you need to set HSTS’s Max-Age attribute to at least 6 months.
And that should do the trick! I truly recommend going through the entire administration panel at this point – there is a ton of hidden and useful features. In fact, let me briefly mention my favourite ones.
- The entire Analytics section is sweet, and complements Google Analytics nicely;
- DNS ↝ DNSSEC allows you to further secure your domain, but support on your domain’s registrar’s side will also be needed; which is why I transferred my domain recently away from IGNUM to Namecheap, which so far seems to be an amazing (and cheap!) registrar that I can wholeheartedly recommend;
- DNS ↝ CNAME Flattening is an always-on feature that allows you to not specify an
Arecord for your apex domain and instead use a
- Speed ↝ Brotli further compresses your site’s traffic;
Pretty amazing for a free service, isn’t it? There’s just one last thing to mention…
By employing Cloudflare to cache your site, you may see some delay before newly published articles or pages appear to your visitors. Or better said, you would be able to see some delay if I didn’t have a handy solution ready.
In my previous article on this topic, I mentioned something about cache purging – and cache purging is exactly what you need to do to indicate to Cloudflare that new content is available on your site. You can do so by calling appropriate API method, preferably as a part of your site’s build process, exactly as I mentioned in the previous article. You can find your domain’s zone ID in the Overview section while your API key hides in My Profile which you can access by clicking on your e-mail address in the top right in Cloudflare’s administration panel.
Congratulations on having secure and, unless you went absolutely nuts with Cloudflare’s applications, fast website! 😜
Well, it looks like most of this article might as well be obsolete as GitHub announced HTTPS support for custom domains. You should probably follow that path in the future, but I’ll keep this article up for historic reasons and because I still think Cloudflare is an interesting service that offers a lot of useful features for any website.
For example, I have a
CNAMErecord on this apex domain that points to
cellane.github.io, and it works just fine and apparently resolves even faster than an
Arecord – how is that possible? Personally, I suspect black magic! ↩︎