[jannic]

> Certificates signed by TrustCor that were issued before December 1st will still be trusted (for now); certificates issued on December 1st or later will not be.

How does this work? If TrustCor is no longer trusted, what keeps them from creating certificates which claim to be issued before December 1st, even after that date?

[pimterry]

> what keeps them from creating certificates which claim to be issued before December 1st, even after that date?

See https://groups.google.com/a/mozilla.org/g/dev-security-polic... for the actions proposed depending on how the TrustCor situation plays out:

> If there is reason to believe that the CA has mis-used certificates or the CA backdates certificates to bypass the distrust-after settings, then remove the root certificates from Mozilla’s root store in an expedited timeline, without waiting for the end-entity certificates to expire.

Right now, they're being slowly removed for poor behaviour in general, but there's no direct evidence of abuse of CA powers. If any clear evidence of that appears in future, including backdating certificates, then they'll be completely removed from the trust store immediately.

[AceJohnny2]

Certificate Transparency [1]: Public logs of issued certificates.

[1] https://en.wikipedia.org/wiki/Certificate_Transparency

[daveoc64]

Assuming the untrusted and unreliable CA actually follows the rules and publishes things to the CT log.

[pimterry]

If you don't then the certificates usually aren't usable at all. All modern browsers should reject certs from any root CA if the cert isn't correctly included in a CT log.

[est31]

Firefox doesn't: https://bugzilla.mozilla.org/show_bug.cgi?id=1281469

(But it's the only browser that doesn't support CT)

[DethNinja]

Do modern browsers check this though? It would introduce a large latency to each request, I bet none of the browsers do that.

Moreover, Chrome removed the browser extension API for TLS certificate details, so it is not even possible to do CT log verification via extensions.

Only way to do CT log verification would be by customising an existing TLS MITM software. As far as I’m aware no such solution exists at the moment.

Certificate system is actually rather insecure, and although solutions are possible to develop, nobody has taken time to do it.

[nmjohn]

> Do modern browsers check this though? It would introduce a large latency to each request, I bet none of the browsers do that.

Yes they do. Only firefox doesn't.

[siebenmann]

Chrome and Safari require that TLS certificates include cryptographic promises of future log inclusion ('SCTs') from N trusted CT logs. As far as I know, neither of them actually contact the log's API endpoints to make sure that this has gone through, but in practice IMHO it's not much of a security gap for various reasons.

[jsmith45]

The SCT is a promise of the log to include the certificate (or pre-certificate, which is used for embedded SCTs) within a time window. The only way a cert could have a valid embedded SCT is to have actually sent the pre-certificate to the log in question.

The SCT contains a signature over some log related information (which is also included in the SCT itself) and everything in the pre-certificate except the signature and poison (which means everything in the real cert, except the SCTs and signature). This means the browser can reconstruct the signed data and verify the signature.

Thus the only way to have a valid SCT and not have at least the pre-certificate show up in the log (after the merge delay) is if the log operator/software messed up. For transparency purposes, a pre-certificate is basically as good as a full certificate, although if I recall correctly the CAs are also supposed to submit the full certificates too.