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

[axaxs]

Great explanation. As someone getting into automated customer ssl cert setup, i've found a lot of people have this misconception that it's some super secret sacred identity, when really it's more about machine to machine trust imho.

[AstralStorm]

This is true except for the case of extended validation certificates. These should be actually validated as sanctioned by the registering entity and the entity should also be verified.

[jerf]

Correct; that is what I mean by "low-class SSL certs", but thank you for using the correct term (which escaped my mind at the time). If GitHub got an extended validation cert, we have a real problem on our hands.

[pfg]

To be more precise, it would be a problem if GitHub got an Extended Validation certificate with the organization field containing the name of the domain owner rather than GitHub itself.

It would in fact be perfectly fine for a CA to issue an EV certificate containing "GitHub, Inc." and a domain that GitHub does not actually own, but which they control because someone pointed their A or CNAME record to GitHub pages. The Extended Validation Guidelines[1] do not require domain ownership for the organization requesting the certificate, it's enough to control it in a way that allows you to complete one of the blessed validation mechanisms defined in the Baseline Requirements.

[1]: https://cabforum-travis-artifacts.s3-us-west-2.amazonaws.com...