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).
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.
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.
I think they should just add a line in the UI instead of hiding the info deep in tickets or issue, but that's a mere communication issue.
Overall, it's not surprising, and actually good for the user.
On letsencrypt.org:
In Progress:
These large providers are currently rolling out support for Let’s Encrypt for custom domains.
You may or may not be able to enable support in their control panel,
or you might notice certificates have recently been issued for your domains hosted with these services.
Blogger
GitHub Pages
> 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.
Github can and should ask Let's Encrypt to revoke the certificates, the API lets them do that by proving it's their certificate.
There's a suitable OCSP cause code like "obsolete" but I can't remember if you can set the cause code in ACME.
I also can't remember whether there's an API for legitimate owners to revoke a cert issued to someone else that's no longer OK. Let's Encrypt does have to be able to do that, but if there's no API it might be very manual.
> I also can't remember whether there's an API for legitimate owners to revoke a cert issued to someone else that's no longer OK. Let's Encrypt does have to be able to do that, but if there's no API it might be very manual.
You can do that by going through the usual challenge process in ACME and obtaining an authorization object for all names on a certificate. Any ACME account who is authorized to issue certificate for these names can also request revocation for existing certificates (even if owned by different ACME accounts).
(You're a bit screwed if the certificate you want to revoke also contains names from other users. This is a good argument for a "one name per certificate" or "only the names of one user per certificate" policy for such implementations.)
At least with Let's Encrypt, you can revoke a certificate issued by a different ACME account, as long the ACME account you are revoking from has a valid authorization for all of the DNS identifiers on the certificate being revoked.
Of course, this is useless if the certificates were issued under a different CA, so your point is still valid. Prevention is better :) !
Actually this was exactly what happened and surprised me. I was moving my blog out of GitHub Pages to a self-hosted solution, and it's only after switching DNS and generating the cert for my own server that I noticed that GH Pages was ALSO serving the old version of the blog over HTTPS.
I didn't know about LE revocation mechanism at the time.