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. GitHub hosts a huge number of project, personal, and conference sites that use custom domains -- including GitHub's own CodeConf site -- which all continue to put their users at risk.

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 -- including GitHub's own CodeConf site. 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!


    Having read this I thought it was very informative. I appreciate you spending some time and energy to put this information together. I once again find myself spending a lot of time both reading and leaving comments. But so what, it was still worthwhile!

  2. FiveYellowMice

    Finally! GitHub Pages now officially support HTTPS!

  3. albuic

    Hi, you can also add a rules in cloudflare to always use https but it only solve one problem !

  4. Jason

    One alternative is to instead use Bitbucket + Aerobatic. SSL for custom domains is supported.

  5. Beni Cherniavsky-Paskin

    Another catch: acessing a directory without trailing slash redirects back to http. (for the unfamiliar, while isaacs/github collects lots of community feedback, it's a not an official channel to Github)

  6. Vincent Tam

    On my site set up with Jekyll-Bootstrap, I tried setting the canonical URL:

    <link rel="canonical" href="%7B%7B%20site.url%20%7D%7D%7B%7B%20page.url%20%7D%7D">

    But I got

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

    in "index.html" on my site deployed at GitHub Pages. I tried replacing with "site.url" with "BASE_PATH", then it works like a charm. When I click on the upper left hand corner for the home page, the HTTP version was no longer displayed.

  7. Beni Paskin-Cherniavsky

    Small tip: old addresses have to be changed to Using still results in a mixed-content error because it redirects (301) back to HTTP://

    No idea if this redirect to http is intentional part of mitigating attacks on [] or just an oversight.

  8. Beni Paskin-Cherniavsky

    I just got a similar response to @dentarg. Eric: the caveat "But be careful. This is a tempting, but incomplete solution." should be extended to the whole setup.

    The upside is that using custom domain via Cloudflare doesn't signifintly degrade security. :-/
    (as long as we accept at all that benefit of last-mile security outweighs harm from illusion of security)

  9. dentarg

    I recently emailed GitHub support about a problem with GitHub Pages and HTTPS. I feel like the answer I got would be useful to add as a comment here (as your post at the moment is the number one result on

    Going to I'm redirected to Should stay HTTPS, don't you think?

    Their response:

    Apologies for the delay in replying. We're looking into the issue, however GitHub Pages does not currently offer HTTPS (SSL) support. While third-party services such as CloudFlare, may in some cases be able to provide that functionality to the end user, at this time, we're not able to offer support for these configurations.

    While HTTPS requests may appear to work, our CDN provider is adding and removing the encryption at their end, and then the request is transmitted over the open internet from our CDN provider to our GitHub Pages infrastructure, creating the appearance of trustability.

    This is why we do not yet officially support HTTPS for GitHub Pages. We definitely appreciate the feedback and I'll add a +1 to this item on out internal Feature Request List.

  10. Ylon

    There's one more thing you can do: set <link rel="canonical" href="https://…"> to point to the HTTPS version of the page.

    This makes it more likely that search engines will point to the HTTPS pages, and should snowball into your other links.

  11. Niel

    $20/month from cloudfare looks too steep. We can get a cheaper shared hosting for that price.

  12. Kin Lane

    I'm all setup on Cloudflare, and awaiting for Github to support. So very important.

  13. Eric

    @Noah - Cloudflare's Universal SSL is great, but the example in this post is using "Strict SSL", which is where CloudFlare uses verified HTTPS to hit the backend server (in this case, GitHub's servers).

    Universal SSL uses "Flexible SSL", where only the connection between the user and CloudFlare is encrypted. This is obviously a lot better, but doesn't offer quite the same guarantee.

    I don't consider this a fully solved problem until Strict SSL is possible, which means that GitHub Pages itself needs to commit to SSL support. For an example of what CF's Flexible SSL can lead some people to do, check out this thread, where the MayDay PAC uses CloudFlare Flexible SSL to accept donations:

  14. Noah

    cloudflare is now offering ssl for free in their 'universal ssl' campaign. It worked perfectly for me as a solution for using ssl on GitHub pages with a custom domain after setting up some page rules.

  15. James B

    Hi Eric, Thanks so much for this tutorial!

    I am planning on using a combination of GitHub Pages and MailChimp embedded forms to create product landing pages with email sign-up boxes for free.

    That https enforcing JavaScript snippet is a gem, thanks again.

  16. Sean Wilkinson

    Thanks! Your blog post is appreciated. I have had similar experiences with trying to set up CloudFlare for my project's homepage, which consists entirely of static content. It's silly, in a way, for me to complain that I wish I could use a security-turned-CDN (CloudFlare) to proxy to a CDN (GitHub Pages) to serve content from a custom domain name over SSL, though ... :-P

  17. Eric Mill

    @Ron - CSP maybe, but the HSTS spec specifically forbids allowing http-equiv elements to apply HSTS:

  18. Ron

    It may be possible to use meta[http-equiv] HTML elements to activate HSTS and CSP for GitHub Pages.

  19. _pants

    Thanks for the great post raising awareness about this, it's super important!

    Just wanted to add a tip: Amazon CloudFront now offers free SNI for custom SSL certs plus http-to-https redirection. From

    CloudFront now supports Server Name Indication (SNI) for custom SSL certificates, along with the ability to take incoming HTTP requests and redirect them to secure HTTPS requests. Both of these features are available at no additional cost to all users of CloudFront.

    So this means you can set up a CloudFront distribution on your custom domain using your custom SSL cert that mirrors your GitHub Pages site, for just pennies a month:

    The docs at are excellent.

    Another tip, if you don't have a certificate already: You can get a class 1 cert from StartSSL for free:

    Last tip: If you want to point your root (apex) domain at your CloudFront distribution or GitHub Pages site, CloudFlare will allow you to put a CNAME at root, and now does CNAME flattening to make this RFC-compliant, for free: (before this you had to use something like DNSimple's ALIAS records starting at $8/month as recommended in

    Hope this helps.

  20. John Roberts

    Thanks for the mention of CloudFlare. Beyond the SSL features, you may also force HTTPS use at the edge by setting up a Page Rule in CloudFlare. Could be easier than forcing a redirect at the server, though both can work as a complement:

    Obvious disclaimer: I work at CloudFlare.