GitHub Pages Now (Sorta) Supports HTTPS, So Use It

published by Eric Mill on
Update, June 2016: GitHub recently announced official HTTPS support for domains on GitHub Pages!

This is excellent progress, especially because for new sites, HTTPS is mandatory. Existing sites can opt-in to server-side HTTPS enforcement.

Of course, the work's not done until GitHub Pages supports HTTPS for custom domains.

But this is clearly involved a ton of CDN and infrastructure work by GitHub that will make custom domain HTTPS support easier, and it means that the GitHub Pages team made HTTPS support a priority for its finite engineering time. That deserves plenty of kudos, and bodes well for future work.

I've updated some instructions below to reflect GitHub's new options. You can also follow this long-running GitHub Issues thread for community updates on further developments.

Recently, GitHub Pages began supporting HTTPS for * domains, like this one and this one.

In my opinion, this is a huge deal - GitHub Pages is the only major, free, general-purpose web host which also offers a secure channel. Given how many simple and powerful uses GitHub Pages has, and how vital secure and confidential connections are to the future of the web, I see this as a big step forward for developers, GitHub, and everyday people.

There are two major catches:

Enforcing HTTPS for sites

(This section updated in June 2016 to integrate GitHub's new HTTPS support for

First, begin enforcing HTTPS server-side.

Second, add or update canonical URLs to tell search engines to use the HTTPS version of your website.

Specifying a canonical URL looks like this:

<link rel="canonical" href="" />

In Jekyll, this looks like:

<link rel="canonical" href="{{ site.url }}{{ page.url }}" />

Where you've set the url field in your site's _config.yml file. See here and here for an example.

(Thanks to Ylon for suggesting this!)

And of course, always link to your own site using its https:// URL. Go through any supporting sites or blog posts or material and update the link. If there are any prominent external links to your site, ask the site owner to update their link to use https://.

Using a custom domain with CloudFlare

[Update: Rewrote this section later in 2014, after CloudFlare released their free SSL plan.]

CloudFlare now offers free SSL termination for any website they host, under their "Universal SSL" plan.

However, until GitHub Pages or CloudFlare fix things, you'll only be able to encrypt the connection between the user and CloudFlare. The connection between CloudFlare and GitHub Pages will need to remain in plaintext, using CloudFlare's "Flexible SSL" option. For more information on why this is the case, read these comments that lay out how it works.

If you're okay with traffic flowing in clear text between CloudFlare and GitHub, you can turn on SSL for free in front of your GitHub Pages site with a custom domain.

But be careful. This is a tempting, but incomplete solution. I was very disappointed to see the MayDay SuperPAC use this configuration to solicit donations. An attacker who could get between CloudFlare and GitHub could have altered the form in transit to send payment information to anywhere they wanted.

More generally problematic is that the browser has no way of indicating to the user that the connection is not fully secure. Right now, people generally expect that if there's a lock symbol in the browser, the connection is secure between them and the website. CloudFlare's Flexible SSL configuration breaks this expectation, and there is no way from the outside to tell whether a website is using it.

I'm not saying to never use CloudFlare's Flexible SSL - but know exactly what you are doing.

What's next

(This section updated in June 2016 to reflect GitHub's progress in HTTPS support for Pages.)

GitHub needs to work on custom domain support for Pages. GitHub hosts a huge number of developer-oriented project, personal, and conference sites that use custom domains. These not only continue to put their users at risk, they also set a bad example for the overall developer community.

It's a tall order, but this is something that other services in GitHub's position have done. WordPress recently deployed complete HTTPS support for every site, whether they use a custom domain or not, using free certificates from Let's Encrypt. Bitly and Shopify have done the same thing, and Dreamhost now lets any customer easily turn HTTPS on for their domain. The bar is higher now, and GitHub should meet it.

In the meantime, the rest of the us can speed up the transition by switching repos we own that run sites, and filing tickets with others reminding them to switch theirs. I've been filing tickets myself, and I encourage you to do the same!