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

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

You can validate if they've been configured correctly here: 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/

[detaro]

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

[move-on-by]

> you can prevent this by setting CAA DNS records on your own domain

Well this is interesting, I already have a CAA DNS record on my root domain, but of course its also set to 'letsencrypt.org' since that is what I use on my root domain. Although I don't guess it matters since its on the root and not the subdomain

Edit: Actually, looks like a CAA record on the root domain will also limit subdomains. So, although I already had a CAA record setup, looks like this new Github feature will work as expected when it rolls out to my account without any changes since I was already using letsencrypt

[suixo]

I mention CAA DNS records in the end of the post, but unfortunately the last time I checked my registrar did not offer the possibility of creating these records... :(

Oh Dear! looks really interesting (though I won't pay for monitoring my personal blog).

I am not sure I fully understand your HTTP-only remark, since how the communication is made (HTTP-only, HTTPS, IMAP, etc.) is not related on how the certificate is generated (which implies CT).

[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

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

[dane-pgp]

What if you trust them at the time, but then move your domain over to different hosting. Is it possible to revoke the previous certificate, or could your old host theoretically keep hold of the old cert and use it in a MitM attack against you?

Fortunately LE are moving towards shorter and shorter validity periods for certs, which at least limits your risk somewhat.

[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

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

[icebraining]

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

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.

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

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

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

[saagarjha]

CloudFlare "Flexible HTTPS" is not HTTPS in the traditional sense. The connection between GitHub and CloudFlare is unsecured.

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