Using HTTPs with Custom Domain Name on GitHub Pages
When writing my post about taking a screenshot with Webcam,
I encountered some issues when embedding iframes using getUserMedia
API. Indeed,
some Mixed Content
warnings were triggered and code was not executed. This is
because both this blog was served in HTTP. Using HTTPs solves this issue.
It is a long time since I wanted to migrate my GitHub Pages blog to HTTPs. Indeed, using this protocol has a lot of advantages:
- Provide a more secured channel between your browser and visited website,
- HTTPs is faster than HTTP (thanks to SPDY),
- HTTPS is a SEO ranking signal.
GitHub supports HTTPs natively, but only for github.io
domain names. It doesn’t
work with custom domain names. Fortunately, CloudFlare,
a free (for basic needs) DNS/CDN, provides a solution to use HTTPs with a custom domain
name.
Configuring GitHub Pages
First step is to configure your GitHub repository. Go on the Settings
page, and
let’s ensure our repository uses a custom domain name and don’t use HTTPs (both options
are incompatible):
We are now done with GitHub configuration.
Configuring CloudFlare
Migrating our DNS Server to CloudFlare
Let’s go on CloudFlare to setup a new site, using our custom domain name. At the end of the wizard, we need to update our domain name settings to use CloudFlare DNS instead of your current ones. They will then import all our existing configuration on their server.
Just ensure that www
CNAME record redirects to your GitHub pages URL. CNAME
is
just an alias. In this case, we tell DNS to respond address of jpetitcolas.github.io
whenever www.jonathan-petitcolas.com
is queried.
Forcing HTTPs on our GitHub Pages
Now that CloudFlare handles our DNS, we need to force all requests to use HTTPs.
On the Crypto tab, just change the SSL
option to Full
. To better understand
each of these options, here is a picture taken from CloudFlare blog:
Using flexible SSL, all communications between CloudFlare servers and GitHub ones are not encrypted. Not really secured, even if your domain would be served in HTTPs.
However, full modes encrypt all communication streams, even behind CloudFlare servers. In this case, hosting server needs to supports SSL. We need to stay in loose mode, as GitHub won’t validate the SSL certificate with a custom domain name.
Our site is now (depending of DNS propagation time, up to 48 hours) served in HTTPs and is compatible with faster HTTP/2.
Force Redirection to HTTPs Version
Currently, we can access our website on both http
and https
protocols. Yet,
for duplicate content issues, and for visitor’s sake, let’s use https
(and https
only)
for everyone.
We are going to add three rules for our domain (fortunately, we have three rules with the free plan):
- First one enables caching on all URL,
- Second one redirect permanently URL without
www
to the one withwww
, - Last one force use of
https
everywhere.
As a result, if we go on http://jonathan-petitcolas.com/2016/…, we will be redirected to a cached version of https://www.jonathan-petitcolas.com/2016/….
Note the use of the wildcard *
on all rules to match every URL. You can retrieve
the value replaced by the wildcard using the regex-like [$1
, $2
, …] arguments.
About CloudFlare Caching
CloudFlare is also a CDN (Content Delivery Network). It has a lot of servers around
the world and optimizes the way it delivers our data. To take profit of it, we just
had to enable caching using page rules. We can configure it more finely via
the Caching
tab.
We cache every requests to GitHub for 4 hours (by default). Instead, all our requests would be served by closest CloudFlare CDN server, saving fractions of seconds of international data transit. Our static website is already blazing fast, let’s increase again its reactivity.
As we asked for a total cache, we need to purge cached pages at each change. We can either do it using CloudFlare built-in API, or manually. As I don’t publish several posts a day, I can wait a few hours before seeing my post being publicly available. Or I just purge the cache using CloudFlare user interface.
Note there is also a Development Mode
feature. It simply disables the cache layer,
allowing you to check in realtime all your changes. It is especially useful if you
need to debug in production. But nobody does this kind of thing, right? ;)
Updating Disqus Comments
So, our GitHub Pages are now served under HTTPs using a CDN for better performances.
Yet, all our Disqus comments have disappeared. Disqus is a
comment system provider pluggable on any websites, including the static ones. It saves
comments according to page URL (at least without any specific configuration). As we
switched from http
to https
, URLs are not the same, and we lost all our comments.
Fortunately, Disqus provides a way to deal with URL changes, using their Url Mapper. First, go on Migrate Threads page and click on “Start Url Mapper” button. Then click on the “download a CSV here” link. We now have to wait a few minutes, time for a download link to be sent to our email.
Once downloaded, let’s open it in our spreadsheet software. We may use awk
, but that’s
too geeky, so let’s be pragmatic. ;)
cd ~/Downloads
gunzip jonathanpetitcolas-2016-11-08T07-05-36.582361-links.csv.gz
# open it in your spreadsheet software
gnome-open jonathanpetitcolas-2016-11-08T07-05-36.582361-links.csv
Then, we just need to replace http://
by https://
using the following formula
(on LibreOffice):
=SUBSTITUTE(A1,"http://", "https://")
Save your file, and submit it to the Url Mapper. Check your changes, and start migration. All your previous comments should soon be back on your website.