Chinese CA WoSign faces revocation after possibly issuing fake certificates

> R: Sorry, I don't say it clear, please forgive my bad English since my native language is Chinese. As I said this is my fault that we don't understand the Mozilla policy clearly that we don't think we need to report. But now we are clear that all mis-issued certificate case and any reported bug related system change also need to report. I and every related employee all clear now, then we can guarantee we will do it well in the future. Why we log all SSL certificate from July 5th is for full transparency to let all related parties can report to us in the first time after the certificate is issued.

Maybe employ someone with enough English knowledge to read and understand https://www.mozilla.org/en-US/about/governance/policies/secu... ?

The behavior of consumers in the certificate marketplace is part of the systemic problem: nobody cares very much about their CA, as long as it causes the little padlock to display correctly (and, more importantly, for warnings to not display) in users' browsers. That's it; beyond that it's a race to the bottom on price.

If a few CAs went down in flames and in doing so created a nasty firedrill for all their customers (which, on the scale of firedrills, getting new certs issued really shouldn't be that big of a deal, compared to a zero-day vulnerability in some piece of the server stack, which happens fairly regularly), suddenly there might be an interest in acquiring certificates from somewhere other than the cheapest-possible source.

One is to reengineer the CA trust system to delegate limited authority to CAs (e.g. there is no good reason for a CA in the US to be able to sign certificates with Chinese TLD CNs, and vice versa).

The second is to build out the Certificate Transparency project to the point where the revocation of trust due to a mis-issued certificate is immediate, widespread, and automatic.

Note that this is also how a new CA is bootstrapped: initially the certs it issues are cross-signed by some existing CA so they work even in UAs that don't have the new CA in their trust root.

The obvious drawback is that now sites need certs signed by two CAs, and getting them to use even one CA is hard enough...

In the CA world, I would assume this would require a standard protocol across CA to request, renew and transfer certificates from CA providers automatically. A sort of commercial version of the ACME protocol. But that requires lots of infrastructure change not just on the CA side, all servers would have to be updated.

This is long overdue anyway. It is currently way too complex to request, install and keep updated a certificate. And there isn't enough competition in this market.

https://news.ycombinator.com/item?id=8982013

" It's 2015. They're using SHA-1 for everything (NOOOO!). They're based in China, which has just said it wants to ban encryption. It looks like they've messed up OSCP, so even their own cert doesn't pass. Oh, and RC4, TLS 1.0 "

If a CA is being revoked, that's pretty close to the maximum pain they'll feel. But suddenly revoking a CA will cause users the most pain - I'm trying to make that gradual. A competent site would react in the first week when a few users got a mild warning, get a certificate from a new CA, then hopefully complain to the original CA demanding a refund and whatnot.

So you can't trust that information either. As mentioned in a different thread, whitelisting certificates extracted from CT logs is the only really viable choice here.

The only way to do this without the risk of backdated certificates being accepted would be to explicitly whitelist all known certificates that were issued prior to the cut-off date. I'm not sure how practical it is to ship such a large list, though (they've issued > 100k certificates in 2015 IIRC).

https://groups.google.com/d/msg/mozilla.dev.security.policy/...

HPKP pretty much solves this, and is already being used by a large number of high-value targets.

DNS Certification Authority Authorization (CAA) would also be fairly useful in this regard. It's essentially a DNS record set by a domain owner declaring which CAs are allowed to issue certificates for that domain. These records can then be checked by CAs prior to issuing certificates. It's more or less a defense-in-depth mechanism for other domain validation vulnerabilities, and would've probably prevented these incidents if implemented correctly, though not particularly useful if a CA is compromised completely. I suppose it could also be used by Certificate Transparency Monitors to automatically check if issued certificates are suspicious.

Unfortunately, it's not mandatory yet and so far I believe only a small number of CAs have adopted CAA (Let's Encrypt, DigiCert and possibly some others).

> Rather than signing everything with your top level cert, you sign a series of intermediate certs and use those to sign the end user keys.

This is what CAs already do, including WoSign. I'm not sure if signing end-entity certificates with the root key is even allowed by the Baseline Requirements. Unfortunately, having multiple intermediate certificates to limit the number of affected clients does not really help much if the question is whether a CA should be trusted at all due to their track record, which is what we're talking about here.

http://superuser.com/questions/1070664/security-seckeychaini...

Edit: Don't delete them, instead right click each certificate, select "Get Info", Expand the "Trust" panel, and set it to "Never Trust"