[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

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.

[rvnx]

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

https://github.com/isaacs/github/issues/156#issuecomment-366... https://community.letsencrypt.org/t/web-hosting-who-support-...

and so on.

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

[tialaramex]

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.

[pfg]

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

[regecks]

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 :) !

[Ajedi32]

> ACME account you are revoking from has a valid authorization for all of the DNS identifiers on the certificate being revoked

Does this mean that if GitHub did what CloudFlare does and batched multiple domains they serve into the same cert you wouldn't be able to revoke it?

I guess with a 90-day expiry it's not that big of a deal...

[regecks]

Yeah, that's a good point too.

[suixo]

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.