Hacker News Reader

Comment by tvanantwerp | Hacker News Reader

Doesn't appear to work with custom domains.

Cloudflare's free plan includes one-click SSL for custom domains. That's what I use for my github pages sites.

Although it doesn't validate the backend certificate.

In some cases it doesn't even connect with TLS due to some connection issue with GitHub / fastly and you need to set it to flexible (no encryption). I wonder if this new forced HTTPS redirect will change/break that?

I haven't quite worked out the rules yet but some GH pages allow full TLS on CF (but not strict cert validation obviously) and some require flexible. I think org pages need flexible (plain HTTP) but project ones support HTTPS (if on a subdomain)?

This update may change all that so will need to experiment again. If it does break things then any new sites after the 15th may not be able to be made to work. If using a CF page rule or HSTS headers to permanently redirect to HTTPS then this could be a problem.

If that's what you are talking about, you can select "Full (strict)" in the SSL options to enforce origin certificate validation.

https://support.cloudflare.com/hc/en-us/articles/200170416-W...

But this doesn't work because the backend certificate is invalid (it covers *.github.io rather then example.com).

But you'd give cf that cname I think

Last time I tested this cloudflare validated using the domain name, not the cname.

Probably in the works? SNI should make this pretty easy now, right?

Maybe GH doesn't want the responsibility of hosting everyone's private keys.

From the documentation:

> HTTPS is not supported for GitHub Pages using custom domains.

Not unsurprising, but unfortunate.

I'm still using kloudsec for this [1] , they presented themselves on HN sometime last year.

[1] https://kloudsec.com/github-pages/new

We're working on a static site hosting service called PubStorm (https://www.pubstorm.com) that allows SSL on custom domains. It's free; we're also working on some powerful features that will set it apart from gh-pages.

http://help.pubstorm.com/command-reference/storm-ssl-set/

> Doesn't appear to work with custom domains.

Do you have any idea how TLS actually works? If this worked out of the box for custom domains, then GitHub would need to be able to impersonate those domains.

At the very least you'd need a way to upload a private key/cert combo that they could server in response to an SNI request. Given the sheer number of sites that they host (every user effectively has a custom GitHub pages page) that's not really feasible though. Hence only support for *.github.io as that only requires a single wildcard cert.

> Do you have any idea how TLS actually works? If this worked out of the box for custom domains, then GitHub would need to be able to impersonate those domains.

If you redirect your domain to my webserver, I can get a certificate for it. E.g. from Let's Encrypt.

Wordpress.com uses that and offers SSL certificates to "million-plus"[0] blogs with custom domains. It's certainly doable at scale, although I totally understand it not having priority for GitHub (esp if it doesn't fit their current technical setup).

[0] https://en.blog.wordpress.com/2016/04/08/https-everywhere-en...

I would hope not. If Github could generate valid SSL certs for random domains, something would be very broken.

It would just request LetsEncrypt to generate those certs and then prove the "ownership" (more like "control") of those domains by whatever method LetsEncrypt wants (.well-known perhaps?).

Yup, .well-known should be pretty simple for them to implement.

Reply on news.ycombinator.com