Add HTTPS support to Github Pages including custom domains

[konklone]

NOTE to anyone stumbling on this thread - there are many people subscribed, so please do not comment here unless you have something new to add that is not already discussed above in this long, detailed (and I hope helpful!) discussion thread.

---

Update: GitHub announced official support of HTTPS for *.github.io domains, which is awesome, and a clear first step. They clearly intend to move GitHub Pages in a secure direction, and this will help GitHub find and fix bugs as they (hopefully) figure out how to do custom domains.

However, this issue is not resolved yet, as custom domain support is a core issue affecting thousands of websites, including the homepages of many prominent software projects (not to mention GitHub's own conference, CodeConf). GitHub Pages doesn't offer complete HTTPS support until custom domains are supported.

To enable HTTPS for your *.github.io subdomain, flip the switch in your settings as described in GitHub's official documentation. 🎉

---

Github obviously takes HTTPS very seriously. It was early to switch to HTTPS everywhere in the site, and @dbussink has already made some great strides in shoring it up for Github.

Recently, Github has given Pages a proper home and place in the Github suite of offerings. I was extremely happy to see that, because Github Pages is one of my favorite things on the Internet and has amazing potential. It's being used for more than simple project pages, and that's only going to continue as Github's reach and accessibility improves.

Given all that, Github should figure out how to support HTTPS on Pages. Encryption is becoming the standard for the entire web, for many obvious reasons -- to the point that Chrome and Firefox will require HTTP 2.0 requests to be encrypted.

This is an issue I've brought up with @benbalter from Github before, on a few occasions. We talked about it a bit last month on Twitter, and he raised the dual point that most people wouldn't turn on HTTPS, yet turning it on by default would wreck a lot of unsuspecting people's sites with mixed content warnings.

These are good points, but this can be addressed by:

• making HTTPS the default for new Github Pages going forward
• provide an option for existing Pages to opt-in to HTTPS
• provide an option for future Pages to opt-out of HTTPS

In other words: a checkbox, defaulting to on for all future Github Pages.

This is the best of both worlds: no one gets surprised with mixed content warnings, and Github gets to proceed with a strong HTTPS policy that will bring a lot of content into the encrypted Internet (aka the future). People who really have to deal with non-HTTPS content can continue to use Pages by unchecking the box.

So how would this work? Covering *.github.io domains is comparatively straightforward - install a wildcard certificate.

However, if custom domains weren't supported at the same time, this could pose its own problems: I'm unsure how that would impact automatic redirects to custom domains -- it's not considered best practice to redirect from an HTTPS URL to an HTTP one, and I've seen Chrome flag such a redirect as a mixed content warning.

Additionally, it would require potentially confusing language and settings to handle different cases, as people add and remove CNAME files. So, it's probably worth tackling both situations at once.

While there are a few solutions, realistically, I believe this means building a dedicated settings pane for managing private keys and certificates. Certificates would need to be handled at the project level, but private keys could be managed at the user level.

I believe the infrastructure of web hosting can and will rework itself to make encryption on every wire standard and easy for publishers and consumers alike. Github is in a position to really help move that needle, and get huge praise for doing so -- not to mention a competitive edge in site hosting.

This is a non-trivial feature request, but the challenge it poses is why I'm not aware of any major option right now for simple, free, secure web hosting -- and why Github meeting this challenge would be so important. Making it easier for people to do powerful things is what Github is all about.

[konklone]

This ticket is an adapted version of an email I sent Github support on January 23, 2014. I sent another followup on January 27 after hearing no response:

So given today's leak about the NSA and GCHQ using location data from smartphone apps, I wanted to update this thread with some more context, and a real-world example.

We're actually using Github Pages data in our work at the Sunlight Foundation, from the unitedstates/districts project, to serve up GeoJSON files that our popular Congress app for Android directly downloads and renders.

I've already updated our app to use HTTPS for nearly all of its connections, including submission of latitude and longitude to our servers. I've also nudged Mapbox to use HTTPS in its Android SDK, so our downloaded map tiles don't leak information either.

The last remaining issue is the GeoJSON URLs themselves, served from a custom domain, theunitedstates.io, over Github Pages. "Congressional district" is not a very high resolution location indicator, but even still, it is something our app is now leaking to any institution with the capability to scour the Internet's pipes for arbitrary metadata.

After today's leak, I may soon have to move these GeoJSON files outside of Github Pages, to ensure that our app is using HTTPS for everything. We'd like to be able to speak clearly and strongly about how we value user privacy, without having to talk about exceptions.

Thanks for the response, and for taking my request seriously.

On January 29, I got this response:

Hi Eric,

Thank you for the extra information about your specific usage of GitHub Pages. While we understand that HTTPS support might be very important for your specific situation, we cant make any promises whether we will end up adding this feature.

We are constantly aiming to improve all aspects of GitHub and thank you once again for your detailed feedback.

Cheers,
[Name removed]

[konklone]

Finally, I've updated the READMEs for two projects I operate on Github Pages that provide permalink-able resources to the public, unitedstates/districts and unitedstates/images, to mention that Github Pages doesn't support HTTPS, and to email Github about it if they think that's problematic.

[captn3m0]

I'd be happy even if the https support was *.github.io only. Building a secure system for all the certificates and hosting them properly would be hard. But heroku handles this pretty well, so can github.

On a sidenote, heroku does piggyback ssl for all the *.herokuapp.com sites by deafult, although I don't know if SSL support was built in from the start, or was flipped on some day (can't find any references to mixed content warnings on herokuapp.com, so it seems it was on from day 1)

[patcon]

👍

[waldoj]

👍

[konklone]

As @benbalter alluded to on Twitter, Github has now tentatively enabled HTTPS for *.github.io domains!

For example: https://sunlightlabs.github.io/congress/

The configuration is different - here are SSL Labs' reports for github.com and sunlightlabs.github.io. And this doesn't apply to custom domains, or give the project owner the ability to force HTTPS-only interaction (HSTS). It's also not documented or announced anywhere, so theoretically it could go away.

But obviously, it's a terrific step, and gives people on Github the ability to host documentation, a blog, or data over a secure channel.

I'd like to keep this issue open until a few things get resolved, in order of descending importance:

• Github publishes some sort of words somewhere that commit to HTTPS support for *.github.io domains.
• Will Github give users control over whether HTTP will be auto-redirected to HTTPS and HSTS set? (or will Github just start defaulting future Github Pages to HTTPS?)
• Will Github support HTTPS for custom domains?

[queso]

👍

[edudemy]

👍

[supertylerc]

+1. Would be great for custom domains as well.

[likethesky]

+1 for custom domains! This is 2014 after all and GitHub Pages is awesome. Please consider implementing this for custom domains, GitHub. Even if you require a paid account, I'd be fine with that.

[nschonni]

+1. Would be great for custom domains as well.

Sorry, but how would GitHub support custom domains when a certificate must be tied to the actual domain itself. I might be missing something obvious 😉, unless you're suggesting GitHub becomes a Certificate Authority.

[likethesky]

@nschonni No, I don't believe GitHub would need to become a Certificate Authority (CA); a user who has (or purchases) for instance a wildcard cert for their domain--from a 3rd party CA like Comodo for example--would use that cert (say, for blog.example.com hosted on Pages) but GitHub would have to allow users to install the user's cert for that purpose and associate it with their GitHub Pages (I'm just guessing here, but probably something along the lines of the CNAME file, where you commit & push your cert to a special place and/or name--obviously it would have to be a non-public location, because it's a .pem & private key, so again I'm fine with them requiring a paid account and/or non open repo--though I'm no security expert, might be best another location than the origin repo). Quoting @captn3m0 above, "Building a secure system for all the certificates and hosting them properly would be hard. But heroku handles this pretty well, so can github."

[rayshan]

+1

[aaronlifshin]

+1

[adamliter]

👍

[atomicframeworks]

[queso]

It is worth point out that you can use cloudflare to front your project and put the SSL termination there.

[konklone]

@queso It's unfortunately not possible to do this securely, even with Cloudflare. I blogged about this in April, and have kept the post up to date since:

https://konklone.com/post/github-pages-now-supports-https-so-use-it#using-your-custom-domain

You can use Cloudflare to create an HTTPS connection between user and Cloudflare, but not between Cloudflare and GitHub Pages. GitHub would need to update their systems to support presenting a valid SSL cert for the custom domain to CloudFlare, and....I don't know how they would do that.

As an example, MayDay.us uses GitHub Pages and Cloudflare for their donation campaign, and are potentially susceptible to a MITM between GHP and CF. They've acknowledged this, and have accepted the risk for now.

[paulbutcher]

This announcement from Google makes HTTPS support for pages even more important:

http://googleonlinesecurity.blogspot.co.uk/2014/08/https-as-ranking-signal_6.html

[konklone]

The White House launched a website on GitHub Pages today, using a custom domain, which of course breaks over SSL. Here's what I said to them after @csoghoian raised the issue:

Unfortunately, until they do, GitHub Pages is just not a great hosting platform for production websites with custom domains. There's been no movement from GitHub's end since April, so I'm looking to migrate my own away from GitHub until things change.

[RichardOliver]

This please!

[bguiz]

+1 for HTTPS support for github pages on custom domains

[tzach]

+1 for HTTPS support for github pages on custom domains as well

[matt-cook]

+1 Google announcement makes SSL for custom domains a top priority. For Github Pages to continue to be a viable site host we need a method to apply our own certs, even if it requires a paid upgrade.

[dxgldotorg]

@matthewburnett To get wildcard support on Let's Encrypt you have to prove control over your entire domain by providing them with special DNS records.
Since GitHub is doing the provisioning of the certificates your responsibility is to ensure your A records are set correctly for both the bare domain and the www so GitHub can serve the files necessary to complete the challenge.

Just so you understand, I have used Let's Encrypt since it was in public beta, except instead of for a GitHub site it is for a server hosted on a VPS. Just recently I got the wildcards set up, after a significant amount of effort getting the proper command line for certbot, setting up the .well-known/ directory, and adding the necessary DNS records.

[lucario]

I already knew that but thanks anyway

[sergei-ivanov]

I gave up and switched back to CloudFlare for the time being. GitHub really needs to improve the diagnostics, because it is not clear whether the problem is with the DNS cache on their side, or whether there's some DNS config problem on my side. I've checked everything multiple times, including using online versions of dig, to make sure that the correct DNS entries are propagated, and GitHub still tells me that "domain is not properly configured to support HTTPS". Also, if it is not possible to have LE certificate for both apex and www domain automatically procured by GitHub, then it is a no go.

[aofei]

@urda

Sorry, I forgot to tell you that the way I told you before has worked. Now my apex domain and www subdomain can be accessed through HTTPS without any errors.

[robobenklein]

To me it seems that this issue is ready to be closed. It took a few days (probably because of the user rush) but once I got any pages to Not yet available for your site because the certificate has not finished being issued. then all I had to do was wait.

@sergei-ivanov , @urda
It still appears www subdomains are not included in automatic cert registration, but I think that should go to Github support and be its own issue. For now I guess we'll use @sheng 's workaround. (Thanks! Problem being you might have to do that domain swap every time the LE cert expires for the subdomain though...)

[urda]

For reference, this was what @github support sent me:

Hey Peter,

Apologies for missing that, It looks like you already had it set up that way!

We don't currently support issuing a certificate for both www and apex domains at the moment, and only issue a certificate for the domain listed in the input box in the repository settings. The redirect I described—and you already have set up—should work fine, but only if you don't specify a protocol when creating your links.

As you explicitly linked to https://www.urda.cc, the browser will be forced to look for a certificate, but there won't be one available. If you use a protocol-less link www.urda.cc or explicitly state http://www.urda.cc the redirect should push you to the correct place.

Hope this clears things up!

So it seems that the www is not issued. I imagine the workarounds that @sheng and others listed here just generate a valid cert, but won't be renewed when the time comes. Until GitHub supports the auto-generation of the www cert, I don't think enforcing HTTPS on your GitHub pages website is a good idea at the moment.

[strugee]

Until GitHub supports the auto-generation of the www cert, I don't think enforcing HTTPS on your GitHub pages website is a good idea at the moment.

Why, exactly? Does "Enforce HTTPS" just do a permanent redirect or does it do HSTS too? I can't actually find any documentation on it.

[dxgldotorg]

@strugee If they were to add HSTS wouldn't that make the fix that @urda mentioned not work due to HSTS rewriting to HTTPS before the browser even makes the request?

[aofei]

@robobenklein, @urda

I'm not sure how GitHub will renew the certificates. There may be a trigger or something trying to renew in the last month of the certificates. The renewal may be based on the CNAME files, maybe not, or even just according to the certificates they have successfully issued. Therefore, we can only wait until July 30th to know whether the domains that has successfully issued certificates can be renewed without being in the CNAME files (suppose they have the correct DNS configuration). Or, you can ask GitHub support.

But anyway, I believe GitHub will solve this problem as soon as possible (probably before July 30th). So, for the time being, it's not necessary for you to get entangled with this problem too much.

[heshengbang]

I have published my blog with https weeks ago, but my domain is out-of-date and can't renew, so i changed new domain yesterday. but the button Enforce Https can't click and with info
Not yet available for your site because the certificate has not finished being issued . some people above said it's need some time to generate certificate, , so how long need i wait for https certificate?

update: ok, i got a new error info
Unavailable for your site because your domain is not properly configured to support HTTPS . it seems like some mistakes i have made, i will check it again....

[arendtio]

@heshengbang I got my certificate last week and it took about 6 hours between the CNAME commit and the certificate being issued.

[wjdp]

I've still got the Not yet available for your site because the certificate has not finished being issued message for >12hrs now.

[z2oh]

@wjdp @heshengbang

If you e-mail GitHub support, they will get your certificate issued in a few minutes.

The contact form is here: https://github.com/contact

[vmstan]

@z2oh I wish that were true. I contacted them on Saturday and again this morning, and total darkness. It initially said I wasn't configured properly, so I changed the DNS to A records instead of CNAME and then waited 24 hours, but have been stuck with not finished being issued since then. I moved the config from Cloudflare's SSL to direct on pages to take advantage of their CDN, thinking it'd be a more native experience but now my site has dropped off the world for anyone who'd previously visited due to HSTS enforcement.

[vinniejames]

If you already have a custom domain associated, you have to turn it off, then back on again in order for the option to appear (after updating your DNS)

[vmstan]

I've tried that, a few times. Same result.

[bardiharborow]

All the above issues seem to have sorted themselves out as the issuance load decreased.

@isaacs @konklone this can be closed now.

[konklone]

All the above issues seem to have sorted themselves out as the issuance load decreased.

@isaacs @konklone this can be closed now.

I agree! Closing. 🎉

My sincere thanks to GitHub for getting HTTPS done for all of GitHub Pages, including custom domains and including those hosted with apex records. It's a significant infrastructure investment, but the right thing to do for GitHub's users, visitors to GitHub's hosted sites, and for the web. Thank you!

[MickaelBergem]

As a side note: it still seems that certificate renewal is in a beta phase - one of my website had a expired certificate for about 48h (low-traffic one, so I didn't notice in the first place). I went to the HTTPS setting page ("your certificate is not yet ready"), did nothing, and the certificate was renewed at around the same time (I cannot say it was related though).
HTTPS was not enforced for this particular website.

[berkarslan-cs]

Certificate renewal is not working for my case too. I'm not sure whether they have support for this. It gives an error "Not yet available for your site because the certificate has not finished being issued." and Enforce HTTPS checkbox is grayed out. I have to change the domain name back and forth to trigger the renewal process but it causes down times (users see invalid cert error).

[aofei]

@berkarslan-cs

You can contact GitHub Support to speed up the issuance of your certificate: https://git.io/c

[AnirudhGoel]

I have published my blog with https weeks ago, but my domain is out-of-date and can't renew, so i changed new domain yesterday. but the button Enforce Https can't click and with info
Not yet available for your site because the certificate has not finished being issued . some people above said it's need some time to generate certificate, , so how long need i wait for https certificate?

update: ok, i got a new error info
Unavailable for your site because your domain is not properly configured to support HTTPS . it seems like some mistakes i have made, i will check it again....

Refer to this post in case you still haven't resolved it yet.