
GitHub Pages generated a TLS cert for my own domain - suixo
https://blog.securem.eu/serverside/2018/04/18/github-pages-generated-a-tls-cert-for-my-own-domain/
======
_hyn3
This is a feature, not a bug.

You asked them to host your site. They secured it.

Github is the designated endpoint for your site traffic, so they can not be
'rogue'. You _explicitly_ granted them control over that endpoint, and their
securing that traffic does not diminish your security in any way.

It's free hosting, version controlled, and now with a free TLS security
upgrade. That's actually pretty awesome.

------
regecks
I mean, it's kind of overstated to call it rogue. A new feature of Github
hosting, sure. It's a pretty common practice to do it automatically in hosting
and CDNs. cPanel does it, Cloudflare does it (by themselves adding up to
10-20+% of all certificates currently trusted), a immeasurable number of SaaS-
es and blogging/ecommerce platforms do it. I saw one user freak out when
FastMail started doing it too for domains pointed to their static hosting.

From a Web PKI perspective I feel it's fine. DV is DV after all.

I do always create CAA records for my owns domains though, even if it's just:

    
    
        issue ";"
        issuewild ";"

~~~
suixo
To me it felt rogue since it had been generated without me knowing nor
expecting it, whereas I expect CloudFlare to do it. This is not an official
feature of GitHub... But I understand the word may be too strong.

For CAA I would love to, but my registrar still doesn't allow me to create
these kind of records :/

~~~
jerf
I've banged on this before in HN, but SSL certificates do not mean what many
(if not most) people here seem to think they do. They do not mean that you are
communicating directly with a person, or even that some person approved the
communication, or the same for a company. It may sound silly when I say it,
because _obviously_ we aren't actually getting webpages from a person, but
it's important to internalize.

They mean something much more like "you are communicating with a machine
authorized to respond on this domain by the owner of that domain". There is no
obligation that the machine in question belongs to the domain owner. So when
you delegated the (sub-)domain to GitHub, you also delegated the ability to
generate at least low-class SSL certs to verify that delegation is correct and
authorized and that HTTPS is legal.

What's important is that nobody can get that authorization without your
delegation. And even with Let's Encrypt, you should find you can't just stroll
out and get a certificate for any domain you choose. At some point you have to
have control of the domain itself to get a cert.

(This is also why I have no problem with anything Cloudflare does with a
certificate. There is no reason that they can't be shared with an authorized
delegate by the domain owner. What matters is that CloudFlare can't do it
_without_ authorization, and if the owner wishes to revoke that delegation
they have a clear path and CloudFlare can't do anything about it.[1] Cert
delegation happens all the time, though; everyone running their HTTPS website
off a hosted VM image is delegating the actual HTTPS-ing to the VM host, for
instance.)

The tricky bit here is that you did not fully understand what you were
authorizing when you delegated the domain to GitHub. No criticism intended,
this is complicated business. It somehow needs to be fixed but heck if I know
how.

[1]: In this case, note that CloudFlare may have a valid cert for your domain
for a while after you leave, but when people check DNS to find where your
domain is, they'll connect to you rather than CloudFlare. This is not a
CloudFlare-specific issue, it would apply to GitHub here or any other
delegate. The fundamental gap here is that domain delegation has no temporal
component and SSL certificates do; an impedance mismatch is inevitable. In
theory you ought to be able to revoke their certificate but that's a shipping
container loaded with cans of worms.

~~~
suixo
Thanks for the detailed post. The rogue word seems to be a bit too strong, as
I totally understand _how_ GitHub generated the cert thanks to Let's Encrypt.
The surprising bit is that when granting them the right to handle all internet
traffic for the given domain (back in 2014), I wasn't expecting them to use it
to generate certificates.

Then Let's Encrypt was released to the public (yeah), and today I am happy
that GitHub generated this cert. However, I was surprised to see it was
generated "in my back", without any kind of notice and no public documentation
of the feature.

~~~
BuildTheRobots
> The surprising bit is that when granting them the right to handle all
> internet traffic for the given domain (back in 2014), I wasn't expecting
> them to use it to generate certificates.

I hate to flog a dead horse, but considering you were specifically pointing
the domain at them for them to host HTTP, them then securing that really
shouldn't be surprising. If they'd started running other services on it (eg
email) then I'd start being surprised. HTTP host hosting HTTPs though...

More granular DNS records would be interesting for the future. The ability to
say "this host resolves to that IP but ONLY for web traffic and nothing else"
(an "ahttp" record) idea intrigues me.

~~~
synotna
This already exists: SRV records

~~~
BuildTheRobots
Of course it does; I'm an idiot. Though it does seem like very few
applications (I can't find a single mainstream browser) that actually support
using them. I do wonder why not.

~~~
jimktrains2
Kerberos and AFS use it! There a few others that can, but it's client
dependent. It would be nice if more things supported it out of the box.

------
Mojah
If you don't want this, you can prevent this by setting CAA DNS records on
your own domain. How this works is described here: [https://ma.ttias.be/caa-
checking-becomes-mandatory-ssltls-ce...](https://ma.ttias.be/caa-checking-
becomes-mandatory-ssltls-certificates/)

You can validate if they've been configured correctly here:
[https://dnsspy.io/labs/caa-validator](https://dnsspy.io/labs/caa-validator)

The article is pretty strongly worded for something that isn't all that bad.
Yes, they issued a certificate, but you've sort-of given them permission to do
so by hosting your content with them. If they own/control the server, they can
get their certs validated.

It's a pretty good example of why you'd want something as Certificate
Transparency even on HTTP-only domains, to know _when_ someone issues a
certificate without you knowing about it. I use Oh Dear! app for that feature:
[https://ohdearapp.com/](https://ohdearapp.com/)

~~~
detaro
If you recommend your own (especially paid) services, please mention that they
are yours.

~~~
lma21
a completely honest question, what's wrong with recommending a product without
mentioning if we're affiliated or not with that product?

~~~
detaro
It's advertising misleadingly pretending to be not-advertising. If you have a
potential motive apart from "I genuinely believe this is the best
recommendation I can give you" for making a recommendation, you probably
should disclose that. Especially in a community like HN, where talking about
your own stuff is somewhere between accepted and encouraged, I can't think of
good reasons _not_ to do it.

~~~
lma21
Thanks for this insight! Now i see the difference and where bias could play a
role when recommending a product in case we're affiliated with. In fact, I see
this widely used only in the HN community.

------
snowwolf
This is the intended behaviour and something Github Pages users have been
asking a long time for:
[https://github.com/isaacs/github/issues/156](https://github.com/isaacs/github/issues/156)

It's using LetsEncrypt under the hood, and only generating a cert for the
custom cname pointing at the Github page.

------
y4mi
I really don't see the problem. Once you set your cname record to GitHub,
you've essentially yielded all control to them.

If you don't like that, don't set a cname record.

~~~
rvnx
From GitHub themselves:

"GitHub Pages sites have been issued SSL certificates from Let's Encrypt,
enabling HTTPS for your custom domain. This isn't officially supported yet and
it's not possible for you to enable and enforce it on your sites at this
time."

~~~
suixo
Could you please provide a link to this page? I wasn't able to find anything
like this on the docs ([https://help.github.com/articles/securing-your-github-
pages-...](https://help.github.com/articles/securing-your-github-pages-site-
with-https/) and related)

EDIT: found out the "official statement" here
[https://gist.github.com/coolaj86/e07d42f5961c68fc1fc8#gistco...](https://gist.github.com/coolaj86/e07d42f5961c68fc1fc8#gistcomment-2370070)

------
colinbartlett
There was some discussion recently on this pull request that Github was
rolling this out to some accounts:

[https://github.com/isaacs/github/issues/156](https://github.com/isaacs/github/issues/156)

~~~
suixo
Thank you! This approves the gradual release thesis, although I am surprised
that no communication was made by GitHub.

------
iofiiiiiiiii
You gave GitHub the right to use your domain to serve content (including over
HTTPS) when you pointed your domain at GitHub servers. This is not a problem.

~~~
suixo
There is no huge problem, just an interrogation over how this happened since
the UI doesn't allow it and the documentation states this is not possible.

------
suixo
OP here. Thanks to all your rich comments, I have updated the post with the
final conclusion:

 _GitHub is gradually (and silently) deploying HTTPS to custom-domains
websites hosted on GitHub Pages, using DV from Let 's Encrypt_.

------
anilgulecha
This would be good, preferable and the right thing to do, expect with
intimation, and an opt-out.

The author has the right to be annoyed that this was done without
notification. (though I would say despite how it was done, there was no-harm
no-foul here). I also eagerly await this change to my own github-pages hosted
custom domain sites.

------
ams6110
I didn't realize they were doing this, but sure enough a domain I host on
github pages now responds on https with a Lets Encrypt cert. Cool.

They are not redirecting port 80 traffic though, at least not yet.

------
corobo
> TL;DR: This blog is hosted on GitHub Pages,

In my books that's not rogue. If you don't trust them to serve https why are
you trusting them to serve http? Feels a bit outrage for the sake of it

~~~
icebraining
If you want a practical problem, what about revocation? OP's trust in Github
hosting is revocable at any time by changing the CNAME, but the generated cert
with still be valid for some time (and can be used e.g. to MITM people).

~~~
rvnx
Any CA can issue any certificate for anyone. This is where Certificate
Transparency Log comes into play (this little backdoor in the browsers that
sends the hosts that you visit to Google and friends).

Imagine, you are the host of a domain and you receive a HTTPS request.

What are your possibilities ?

A) Drop the request ? Fallback to HTTP and get the user MITM

B) Self-signed certificate

C) A certificate trusted by a well known authority

D) MITM yourself with CloudFlare ? Put CloudFlare in front then CloudFlare
will proxy the traffic in pure HTTP to GitHub.

Now talking about risks:

    
    
       $ openssl s_client -servername blog.securem.eu -connect blog.securem.eu:443 | openssl x509 -noout -dates
    
       notBefore=Apr 15 15:48:38 2018 GMT
       notAfter=Jul 14 15:48:38 2018 GMT
    

[https://letsencrypt.org/2015/11/09/why-90-days.html](https://letsencrypt.org/2015/11/09/why-90-days.html)

The certificates are valid only for 90 days.

It looks like just inventing a problem. If you decided to give control of part
of your domain to GitHub, yes they will be able to serve content on your
behalf. That's normal, and logic.

~~~
icebraining
I don't think it's a major problem, but it does violate the Principle of least
astonishment, which I think we (developers) should strive to avoid.

~~~
hannob
> I don't think it's a major problem, but it does violate the Principle of
> least astonishment,

The principle of least astonishment should tell you that in 2018 HTTPS is
becoming the default and hosting web pages with automated HTTPS should be
expected.

What you should be astonished about is that it took Github so long to support
HTTPS everywhere.

~~~
icebraining
They already supported HTTPS, just not for custom domains.

------
icebraining
Somewhat ontopic, I find interesting that Cloudflare is issuing certificates
for HN, despite HN serving a Comodo cert.

[https://crt.sh/?id=182943715](https://crt.sh/?id=182943715)

~~~
majewsky
They may be using Cloudflare in some regions only, or as a standby to take
over in case of a DDoS on the original host.

~~~
icebraining
Another post in this thread answered it: HN uses Cloudflare's DNS, and they
create a cert even if you just use the DNS.

~~~
detaro
HN doesn't use Cloudflare DNS for news.ycombinator.com, but is actually served
by Cloudflare.

------
snissn
It's kind of github to only make the ssl cert valid for ~90 days

[https://www.sslshopper.com/ssl-
checker.html#hostname=blog.se...](https://www.sslshopper.com/ssl-
checker.html#hostname=blog.securem.eu)

> The certificate will expire in 87 days.

Good reminder for everyone to check their cert expirations!

~~~
majewsky
That's not kindness, that's how Let's Encrypt works. And if you still have
certificate expiration reminders in your calendar, you're doing it wrong.

~~~
dannyw
That’s like saying “if you’re not using <ESx feature released three months
ago>, you’re doing it wrong”.

The vast majority of websites still use traditional, yearly carts without
automation. It may not be perfect, but it’s not the worst thing in the world.

~~~
majewsky
> three months

Three years.

In these three years, I've seen at least 5 outages because of expired certs.
Maybe if you have only one domain, the ROI is not as clear.

------
hidiegomariani
You can use CloudFlare HTTPS + Github Pages = 100% free hosting with SSL

~~~
snowwolf
You don't need CloudFlare anymore, as Github are gradually rolling out native
https support for Github Pages with custom domains (using LetsEncrypt)

~~~
justinclift
Hasn't been rolled out to ours yet (sqlitebrowser.org).

Wish it was though, as we have an open Issue on GitHub from a user about not
using HTTPS. This would mean 1 less open issue. :D

------
subpixel
I have pages on Netlify with their one-click SSL, and more than once the
certificate has (here my ignorance becomes apparent) stopped working, breaking
the site (since https is forced server-side and/or cached by browsers like
Safari). To get the site up and running again I've needed to contact support
and have them manually issue a new certificate.

Maybe this is way easier than handling things on my own, but it seems like an
achilles heel of fully automated SSL.

~~~
icebraining
Sounds like they just have a poor auto-TLS infrastructure. A good system will
(1) try to generate multiple times ahead of expiration and (2) warn humans if
the cert is about to expire.

~~~
tialaramex
Yup, this is definitely a Quality of Implementation issue, like if you go to a
cheap bulk host and every few months your web site is just "down" due to some
idiot error they made.

If it's cheap or free, well, hard to complain.

