This is a feature, not a bug.<p>You asked them to host your site. They secured it.<p>Github is the designated endpoint for your site traffic, so they can not be 'rogue'. You <i>explicitly</i> granted them control over that endpoint, and their securing that traffic does not diminish your security in any way.<p>It's free hosting, version controlled, and now with a free TLS security upgrade. That's actually pretty awesome.
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.<p>From a Web PKI perspective I feel it's fine. DV is DV after all.<p>I do always create CAA records for my owns domains though, even if it's just:<p><pre><code> issue ";"
issuewild ";"</code></pre>
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: <a href="https://ma.ttias.be/caa-checking-becomes-mandatory-ssltls-certificates/" rel="nofollow">https://ma.ttias.be/caa-checking-becomes-mandatory-ssltls-ce...</a><p>You can validate if they've been configured correctly here: <a href="https://dnsspy.io/labs/caa-validator" rel="nofollow">https://dnsspy.io/labs/caa-validator</a><p>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.<p>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: <a href="https://ohdearapp.com/" rel="nofollow">https://ohdearapp.com/</a>
This is the intended behaviour and something Github Pages users have been asking a long time for:
<a href="https://github.com/isaacs/github/issues/156" rel="nofollow">https://github.com/isaacs/github/issues/156</a><p>It's using LetsEncrypt under the hood, and only generating a cert for the custom cname pointing at the Github page.
I really don't see the problem. Once you set your cname record to GitHub, you've essentially yielded all control to them.<p>If you don't like that, don't set a cname record.
There was some discussion recently on this pull request that Github was rolling this out to some accounts:<p><a href="https://github.com/isaacs/github/issues/156" rel="nofollow">https://github.com/isaacs/github/issues/156</a>
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.
OP here. Thanks to all your rich comments, I have updated the post with the final conclusion:<p><i>GitHub is gradually (and silently) deploying HTTPS to custom-domains websites hosted on GitHub Pages, using DV from Let's Encrypt</i>.
This would be good, preferable and the right thing to do, expect with intimation, and an opt-out.<p>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.
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.<p>They are not redirecting port 80 traffic though, at least not yet.
> TL;DR: This blog is hosted on GitHub Pages,<p>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
Somewhat ontopic, I find interesting that Cloudflare is issuing certificates for HN, despite HN serving a Comodo cert.<p><a href="https://crt.sh/?id=182943715" rel="nofollow">https://crt.sh/?id=182943715</a>
It's kind of github to only make the ssl cert valid for ~90 days<p><a href="https://www.sslshopper.com/ssl-checker.html#hostname=blog.securem.eu" rel="nofollow">https://www.sslshopper.com/ssl-checker.html#hostname=blog.se...</a><p>> The certificate will expire in 87 days.<p>Good reminder for everyone to check their cert expirations!
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.<p>Maybe this is way easier than handling things on my own, but it seems like an achilles heel of fully automated SSL.