New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add HTTPS support to Github Pages including custom domains #156

Closed
konklone opened this Issue Mar 8, 2014 · 571 comments

Comments

Projects
None yet
@konklone

konklone commented Mar 8, 2014

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 comment has been minimized.

Show comment
Hide comment
@konklone

konklone 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:

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 commented 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:

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

This comment has been minimized.

Show comment
Hide comment
@konklone

konklone 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.

konklone commented 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

This comment has been minimized.

Show comment
Hide comment
@captn3m0

captn3m0 Mar 8, 2014

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)

captn3m0 commented Mar 8, 2014

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

This comment has been minimized.

Show comment
Hide comment
@patcon

patcon commented Mar 8, 2014

👍

@waldoj

This comment has been minimized.

Show comment
Hide comment
@waldoj

waldoj commented Mar 9, 2014

👍

@konklone

This comment has been minimized.

Show comment
Hide comment
@konklone

konklone Mar 16, 2014

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?

konklone commented Mar 16, 2014

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

This comment has been minimized.

Show comment
Hide comment
@queso

queso commented Apr 29, 2014

👍

@edudemy

This comment has been minimized.

Show comment
Hide comment
@edudemy

edudemy commented May 9, 2014

👍

@supertylerc

This comment has been minimized.

Show comment
Hide comment
@supertylerc

supertylerc Jun 22, 2014

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

supertylerc commented Jun 22, 2014

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

@likethesky

This comment has been minimized.

Show comment
Hide comment
@likethesky

likethesky 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.

likethesky commented 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

This comment has been minimized.

Show comment
Hide comment
@nschonni

nschonni Jun 24, 2014

+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.

nschonni commented Jun 24, 2014

+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

This comment has been minimized.

Show comment
Hide comment
@likethesky

likethesky 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."

likethesky commented 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

This comment has been minimized.

Show comment
Hide comment
@rayshan

rayshan commented Jun 29, 2014

+1

@aaronlifshin

This comment has been minimized.

Show comment
Hide comment
@aaronlifshin

aaronlifshin commented Jul 11, 2014

+1

@emka emka referenced this issue Jul 15, 2014

Open

SSL certificate #3

@adamliter

This comment has been minimized.

Show comment
Hide comment
@adamliter

adamliter commented Jul 20, 2014

👍

@atomicframeworks

This comment has been minimized.

Show comment
Hide comment
@atomicframeworks

atomicframeworks commented Jul 25, 2014

@queso

This comment has been minimized.

Show comment
Hide comment
@queso

queso Jul 25, 2014

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

queso commented Jul 25, 2014

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

@konklone

This comment has been minimized.

Show comment
Hide comment
@konklone

konklone Jul 25, 2014

@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.

konklone commented Jul 25, 2014

@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 comment has been minimized.

Show comment
Hide comment
@paulbutcher

paulbutcher Aug 7, 2014

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

paulbutcher commented Aug 7, 2014

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

This comment has been minimized.

Show comment
Hide comment
@konklone

konklone Aug 12, 2014

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.

konklone commented Aug 12, 2014

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 comment has been minimized.

Show comment
Hide comment
@RichardOliver

RichardOliver commented Aug 12, 2014

This please!

@bguiz

This comment has been minimized.

Show comment
Hide comment
@bguiz

bguiz Aug 13, 2014

+1 for HTTPS support for github pages on custom domains

bguiz commented Aug 13, 2014

+1 for HTTPS support for github pages on custom domains

@tzach

This comment has been minimized.

Show comment
Hide comment
@tzach

tzach Aug 13, 2014

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

tzach commented Aug 13, 2014

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

@matt-cook

This comment has been minimized.

Show comment
Hide comment
@matt-cook

matt-cook Aug 15, 2014

+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.

matt-cook commented Aug 15, 2014

+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.

@z2oh

This comment has been minimized.

Show comment
Hide comment
@z2oh

z2oh May 2, 2018

I emailed GitHub support and got this in response:

Hey z2oh,

I just gave the certification process a nudge for your domain and it looks like you should be all set now!

Feel free to let the folks in that thread know that if their domain hasn't gotten a certificate within a few hours of being set up that they can reach out to us via the contact form for assistance:

https://github.com/contact

Best,
Github Support

Within a few minutes everything is working! Looks like if you are having trouble, just e-mail support.

z2oh commented May 2, 2018

I emailed GitHub support and got this in response:

Hey z2oh,

I just gave the certification process a nudge for your domain and it looks like you should be all set now!

Feel free to let the folks in that thread know that if their domain hasn't gotten a certificate within a few hours of being set up that they can reach out to us via the contact form for assistance:

https://github.com/contact

Best,
Github Support

Within a few minutes everything is working! Looks like if you are having trouble, just e-mail support.

@urda

This comment has been minimized.

Show comment
Hide comment
@urda

urda May 2, 2018

I noticed that if I go to https://www.mydomain.com I get a NET::ERR_CERT_COMMON_NAME_INVALID. Shouldn't my www redirect also be covered by my new forced HTTPS ? HTTPS currently works on my main domain, but not it's www, both hosted as the same gh-pages project.

urda commented May 2, 2018

I noticed that if I go to https://www.mydomain.com I get a NET::ERR_CERT_COMMON_NAME_INVALID. Shouldn't my www redirect also be covered by my new forced HTTPS ? HTTPS currently works on my main domain, but not it's www, both hosted as the same gh-pages project.

@aofei

This comment has been minimized.

Show comment
Hide comment
@aofei

aofei May 2, 2018

@urda

I have already asked GitHub support about this.

This is currently expected behavior. You can work around this by pointing your www CNAME record at your root domain instead of username.github.io. But I will also add your +1 to that feature request internally! I can't say if or when a change will happen, but your feedback is in the right hands.

Best,
Shawna

aofei commented May 2, 2018

@urda

I have already asked GitHub support about this.

This is currently expected behavior. You can work around this by pointing your www CNAME record at your root domain instead of username.github.io. But I will also add your +1 to that feature request internally! I can't say if or when a change will happen, but your feedback is in the right hands.

Best,
Shawna

@urda

This comment has been minimized.

Show comment
Hide comment
@urda

urda May 2, 2018

@sheng

Weird because I am already doing that:

$ dig www.urda.cc +nostats +nocomments +nocmd

; <<>> DiG 9.10.6 <<>> www.urda.cc +nostats +nocomments +nocmd
;; global options: +cmd
;www.urda.cc.			IN	A
www.urda.cc.		300	IN	CNAME	urda.cc.
urda.cc.		66	IN	A	185.199.108.153
urda.cc.		66	IN	A	185.199.109.153
urda.cc.		66	IN	A	185.199.110.153
urda.cc.		66	IN	A	185.199.111.153

urda commented May 2, 2018

@sheng

Weird because I am already doing that:

$ dig www.urda.cc +nostats +nocomments +nocmd

; <<>> DiG 9.10.6 <<>> www.urda.cc +nostats +nocomments +nocmd
;; global options: +cmd
;www.urda.cc.			IN	A
www.urda.cc.		300	IN	CNAME	urda.cc.
urda.cc.		66	IN	A	185.199.108.153
urda.cc.		66	IN	A	185.199.109.153
urda.cc.		66	IN	A	185.199.110.153
urda.cc.		66	IN	A	185.199.111.153
@matthewburnett

This comment has been minimized.

Show comment
Hide comment
@matthewburnett

matthewburnett May 2, 2018

@sheng That isn't a work around. The cert issued still only has the root domain, and no subsequent sub domains, like www. Services like Firebase Hosting include the www on the cert, cloudflare just serves wildcards along with the root. Letsencrypt does support wildcards last I checked.

matthewburnett commented May 2, 2018

@sheng That isn't a work around. The cert issued still only has the root domain, and no subsequent sub domains, like www. Services like Firebase Hosting include the www on the cert, cloudflare just serves wildcards along with the root. Letsencrypt does support wildcards last I checked.

@aofei

This comment has been minimized.

Show comment
Hide comment
@aofei

aofei May 2, 2018

@urda

I think that may be because the certificate about your apex domain has been issued successfully, and the certificate only has the signature of the apex domain. In fact, my current status is the same as yours. Instead, I'm trying to change the custom domain in the repo's settings to the www subdomain. Once the certificate on the www subdomain is issued successfully, I'll change back to the apex domain. I think this might solve the problem because GitHub has two certificates for the apex domain and the www subdomain. I'm still waiting for GitHub to issue a certificate for the www subdomain. If this method works, I will tell you.

And @matthewburnett, Let's Encrypt definitely supports the issuing of wildcard certificates because I've been using it myself for a long time, check it yourself (https://aofei.org).

aofei commented May 2, 2018

@urda

I think that may be because the certificate about your apex domain has been issued successfully, and the certificate only has the signature of the apex domain. In fact, my current status is the same as yours. Instead, I'm trying to change the custom domain in the repo's settings to the www subdomain. Once the certificate on the www subdomain is issued successfully, I'll change back to the apex domain. I think this might solve the problem because GitHub has two certificates for the apex domain and the www subdomain. I'm still waiting for GitHub to issue a certificate for the www subdomain. If this method works, I will tell you.

And @matthewburnett, Let's Encrypt definitely supports the issuing of wildcard certificates because I've been using it myself for a long time, check it yourself (https://aofei.org).

@DXGLdotinfo

This comment has been minimized.

Show comment
Hide comment
@DXGLdotinfo

DXGLdotinfo May 2, 2018

@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.

DXGLdotinfo commented May 2, 2018

@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.

@matthewburnett

This comment has been minimized.

Show comment
Hide comment
@matthewburnett

matthewburnett May 2, 2018

I already knew that but thanks anyway

matthewburnett commented May 2, 2018

I already knew that but thanks anyway

@sergei-ivanov

This comment has been minimized.

Show comment
Hide comment
@sergei-ivanov

sergei-ivanov May 2, 2018

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.

sergei-ivanov commented May 2, 2018

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

This comment has been minimized.

Show comment
Hide comment
@aofei

aofei May 9, 2018

@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.

aofei commented May 9, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@robobenklein

robobenklein May 9, 2018

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...)

robobenklein commented May 9, 2018

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

This comment has been minimized.

Show comment
Hide comment
@urda

urda May 9, 2018

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.

urda commented May 9, 2018

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

This comment has been minimized.

Show comment
Hide comment
@strugee

strugee May 10, 2018

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.

strugee commented May 10, 2018

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.

@DXGLdotinfo

This comment has been minimized.

Show comment
Hide comment
@DXGLdotinfo

DXGLdotinfo May 10, 2018

@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?

DXGLdotinfo commented May 10, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@aofei

aofei May 10, 2018

@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.

aofei commented May 10, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@heshengbang

heshengbang May 14, 2018

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....

heshengbang commented May 14, 2018

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

This comment has been minimized.

Show comment
Hide comment
@arendtio

arendtio May 14, 2018

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

arendtio commented May 14, 2018

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

@wjdp

This comment has been minimized.

Show comment
Hide comment
@wjdp

wjdp May 14, 2018

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

wjdp commented May 14, 2018

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

@z2oh

This comment has been minimized.

Show comment
Hide comment
@z2oh

z2oh 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

z2oh commented 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

This comment has been minimized.

Show comment
Hide comment
@vmstan

vmstan 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.

vmstan commented 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

This comment has been minimized.

Show comment
Hide comment
@vinniejames

vinniejames 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)

vinniejames commented 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

This comment has been minimized.

Show comment
Hide comment
@vmstan

vmstan May 15, 2018

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

vmstan commented May 15, 2018

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

@bardiharborow

This comment has been minimized.

Show comment
Hide comment
@bardiharborow

bardiharborow 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.

bardiharborow commented 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

This comment has been minimized.

Show comment
Hide comment
@konklone

konklone May 20, 2018

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!

konklone commented May 20, 2018

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

This comment has been minimized.

Show comment
Hide comment
@MickaelBergem

MickaelBergem 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.

MickaelBergem commented 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment