[shittyadmin]

> I always wondered why there wasn't a secure way to prevent rogue CAs from creating valid certs, but your explanation pretty much sums it up: this is about enforcing corporate policies and making someone's job easier, not so much security.

Pretty much the best attempt at this I've seen is the Certificate Transparency thing designed by Google and implemented in Let's Encrypt and a few other CAs. Having a public, auditable log of every certificate officially issued could can be used to validate certs, Chrome enforces this with new EV certs and Symantec certs.

[peterwwillis]

We still have to depend on CAs to 'follow the rules', and the client has to support it (does your mail client verify Cert Transparency? does your backend microservice?) and be connected to the Internet, and Google, etc.

There are better ways to handle it, I think, but they may involve changing how we both sign and verify certs.

[hannob]

> Chrome enforces this with new EV certs and Symantec certs.

Chrome enforces this for all new certs since earlier this year.

[tialaramex]

More specifically: Log servers can be shown either a normal X.509 certificate or a "pre-certificate" which is proof that a Certificate Authority intends or intended to issue some particular certificate. Right now these are actually X.509 certs that were "poisoned" to make them useless, but in future they will probably be some other format.

Anyway, when shown a new certificate or pre-certificate, the log server gives you a Signed Certificate Timestamp proving when it saw the document.

Chrome (and eventually Safari and Firefox) require suitable SCTs when shown any modern public certificate or they may conclude the certificate should not exist and fail the connection or mark it insecure, or even report it to Google/ Apple/ Mozilla for investigation.

SCTs get to the browser in one of three ways:

1. Most popular. The site's CA made pre-certificates, logged those, got back SCTs and baked the SCTs inside the real certificate. This changes nothing for a site operator, if you use Let's Encrypt and have never heard of SCTs, don't worry, all your current Let's Encrypt certs are done this way.

2. Less popular: The CA doesn't put SCTs inside the certificate, but it DOES staple them inside OCSP responses. Then you staple an OCSP response into your certificate responses and everything works.

3. Also less popular: The SCTs go in a separate TLS extension when a client connects, saying "Hey, I want SCTs" and they get them back only if they ask for them.