Repository navigation
Add HTTPS support to Github Pages including custom domains #156
Description
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.
Activity
konklone commentedon Mar 8, 2014
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:
On January 29, I got this response:
konklone commentedon Mar 8, 2014
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 commentedon Mar 8, 2014
I'd be happy even if the https support was
*.github.ioonly. 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.comsites 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 commentedon Mar 8, 2014
👍
waldoj commentedon Mar 9, 2014
👍
konklone commentedon Mar 16, 2014
As @benbalter alluded to on Twitter, Github has now tentatively enabled HTTPS for
*.github.iodomains!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.iodomains.queso commentedon Apr 29, 2014
👍
edudemy commentedon May 9, 2014
👍
supertylerc commentedon Jun 22, 2014
+1. Would be great for custom domains as well.
likethesky commentedon Jun 23, 2014
+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 commentedon Jun 24, 2014
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 commentedon Jun 24, 2014
@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 commentedon Jun 29, 2014
+1
aaronlifshin commentedon Jul 11, 2014
+1
adamliter commentedon Jul 20, 2014
👍
556 remaining items
wjdp commentedon May 14, 2018
I've still got the
Not yet available for your site because the certificate has not finished being issuedmessage for >12hrs now.z2oh commentedon May 14, 2018
@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 commentedon May 15, 2018
@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 commentedon May 15, 2018
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 commentedon May 15, 2018
I've tried that, a few times. Same result.
bardiharborow commentedon May 17, 2018
All the above issues seem to have sorted themselves out as the issuance load decreased.
@isaacs @konklone this can be closed now.
konklone commentedon May 20, 2018
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 commentedon Jun 11, 2018
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 commentedon Mar 3, 2019
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 commentedon Mar 3, 2019
@berkarslan-cs
You can contact GitHub Support to speed up the issuance of your certificate: https://git.io/c
AnirudhGoel commentedon Oct 27, 2019
Refer to this post in case you still haven't resolved it yet.
Revert https change