Traditionally it's difficult for browser vendors to revoke a root CA as they want to grandfather in old certificates, so existing sites don't have the rug pulled out from under their feet when their only crime is using a crap CA.
Partial solutions include blocking the CA's certs based on the issuance date or insisting they hand over a list of the certs they've issued - but if the CA is going down in flames anyway, they have no incentive to cooperate; they can backdate certs and destroy their own customer list.
My theory is [1] this is one of the side benefits of Certificate Transparency - CT will give browser vendors a list of certs to grandfather in if they decide to shut down a CA against its will.
That's exactly the internet equivalent of too big to fail banks. And like for banks it is unacceptable. The internet needs its Lehman moment to become resilient again. We should let a Comodo fail.
I think we should just pull the rug out. Site operators need to be more aware of which CAs they're using, and need to feel some of the pain from the failure if they're going to shop for CAs based on anything except price.
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.
Site operators need to be more aware of which CAs they're using
How? I've got no way to judge the security / responsibility of any CA. The amount of money that they charge may have no relation to their behaviour. I don't think anyone has claimed that the CAs who issued wrong certs were charging less than their competitors. You can't blame the CA customers for this.
One sign is that if Symantec has issued rogue certificates, and Google publishes the problem, then it's time to leave.
Of course, the CA would then be incentivized to publish their procedures and show how they intend to fix the breach, which shouldn't have happened in the first place, to regain customer's trust. Or go bankrupt. Let me tell you they wouldn't let their employees do mistakes.
Customers who stay, in the situation that it is discovered that Symantec issues another rogue cert, which causes Mozilla to completely revoke Symantec, can later sue Symantec for harming their business by not applying their public procedures. And here's how the economy gets rid of bad actors. The rule is much tougher for cloud machine providers (EC2 and DO): Should they lose one customers' data, everyone would leave them and go bankrupt, that's why they don't.
In parallel, losing a CA doesn't harm the customers very much, even for amazon.com. They can buy a new certificate in a matter of hours. bzbarsky even says it's commonplace to have the certificates signed by 2 CAs.
Absolutely agree. Pulling the rug is a powerful incentive both for the customers and the CAs. Customers will have to consider the likelihood the CA will be revoked due to poor security practices, CAs will have to show that they're not rubbish.
That's a chicken-and-egg problem, but it would be solved when there's suddenly a lot of site operators with a vested interest in knowing which CAs are likely to fail and which aren't. Right now there's not a ton of interest. CAs are basically selling a fungible, commodity product, so you just buy from the cheapest ones. Searching for "best SSL certificates" thus gets you a lot of articles reviewing CAs, but largely on the basis of stuff like price and ease of issuance. Because that's what people care about.
There would be a slew of reviews of CAs, judging their perceived odds of vanishing in a puff of paperwork, if there was an interest in issuer stability. CAs themselves could probably offer value-added features like guarantees backed by outside parties (i.e. an insurance product) that would pay costs associated with certificate reissuance in the event of malfeasance or incompetence on the part of the CA.
The market would provide, but there has to be demand. Right now there's no demand, because the consequences of getting a cert from a crap issuer has, historically, been approximately zero.
Very often, marketing material and the language used for for that is a good indicator on whether a particular service knows their stuff, or if they appear to peddle fluff... :)
How CAs respond to issues on these mailing lists and in bugzilla is also pretty telling.
In this particular case, there's been concerns raised for several days. An extra vigilant web site operator who sees these discussions might perhaps come to the conclusion that it would be wise to evaluate switching CAs today, perhaps.
Very often, marketing material and the language used for for that is a good indicator on whether a particular service knows their stuff, or if they appear to peddle fluff... :)
We're all doomed then! Asides from LetsEncrypt, most CA web pages are full of marketing fluff :)
I've just been reading through the mailing list discussion, and from that I agree with you completely, WoSign looks pretty incompetent in their responses. If I had a WoSign certificate, I'd definitely be looking around to get an alternative now. However, that's a bit late for 'people power' to force CAs to act better.
You could say the same about your bank - even though you don't really know how they invest your deposit money, you try and gain an intuition based on other factors (stock price, professionalism, reputation, prestige, etc). Not saying these factors -> a good analysis of the creditworthiness of a financial institution but you get the idea.
> Site operators need to be more aware of which CAs they're using, and need to feel some of the pain from the failure if they're going to shop for CAs based on anything except price.
Why? CAs just operate as a tax on sites. Having a certificate doesn't buy a site much; it's typically more for the _users'_ convenience, since they are the ones relying on the CA.
Really, users should pay CAs (probably indirectly), and CAs should issue certs for free. But I doubt that'll ever happen.
For commercial sites, the users are paying indirectly - since the cost of CA would be surely rolled into the maintenance costs, which are surely part of the price of whatever the site is selling.
A viable solution to big CAs is to have all sites have their certs cross-signed by at least two different CAs. Then any single CA can be revoked without affecting any sites at all.
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...
I was thinking the same thing. Assuming it's technically feasible I don't see this as being a huge problem. If your site is important enough that you can't have any downtime due to a CA revocation then you spend the extra time/money up front to get get cross-signed certs. If you don't care, then you just fix the problem when it comes up. If CAs start getting revoked more often then this will just become standard practice.
The solution for big banks is the orderly failure. Things like bail-in, where a bank is required to be able to go through a flash chapter-11 process over a week end. Or the "living will", basically the bank preparing a contingency plan in advance if it needs to wind down its activity.
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.
Transferring certificates from an untrustworthy CA makes no sense. Burn the certificates. Websites should just obtain brand new ones from a different CA. If you are running a website that's important to you, this should be at most a one hour operation (or, if politics and procedures delay you in obtaining a new cert, maybe you should have planned ahead and kept two different certificates on hand already)
By transferring I meant re-issuing automatically a new certificate, not keeping the signature. Of course this requires to re-authenticate the request. And that process has to be automated. A bit like the renewal of the certificate should also be automated.
No, existing certificates should not be reissued. We can't trust that they were issued to the rightful owner originally by the failed CA. Clients should request new certificates and validate their ownership from scratch.
Getting a certificate is an hour's work tops if you are doing the csr dance manually. If you use ACME and letsencrypt it's done in seconds.
EV certificates are more work but if this matters to you then perhaps you should source multiple certificates to begin with, or act quickly when a CA is dropped (I'm sure browser vendors will give at least a few days notice)
Edit: Maybe I misunderstood you. If you just meant that software in general should offer requesting certificates from any provider, then sure, why not just use ACME. CertBot appears to be designed with multiple providers in mind. But this doesn't really have much to do specificially with the case of CAs being dropped from the root. (At first I got the impression you wanted other CAs to "bail out" certificates from the revoked CA)
The validation requirements for 'Extended Validation' certificates can be onerous - complete with in-person ID checks, and photocopies of passports and driving licenses signed by public notaries. I'm not sure automated transfers would be possible.
I suppose you could downgrade on automatic transfer. I've heard people question the value of EV certs, and certainly a working DV cert is better than a revoked EV cert. Or you could insist every EV cert applicant verify their identity with two different CAs.
The certificate system - like the federal reserve - doesn't just fail us in these specifics, but is generally incompatible with the underlying philosophies of distributed technology.
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.
(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).
Sure there is. If you have a .cn domain but don't trust Chinese companies not to MITM your site, you can get a cert from a foreign CA and then pin it using the HSTS preload list.
That way, even if the registry hijacks the domain and sends people to a server with a valid (but fraudulent) cert, you're still protected by the pin.
But why not do both? It's unreasonable that there is a mountain of CAs out there that never sign certs for .us but they still have the capability to do so. The more CAs that can sign a cert for my domain, the more chances that someone screws up. At the very least I agree with limiting CAs to a subset of TLDs for protection from hypothetical things like the Turkish government demanding that a Turkish CA signs a cert for facebook.com. If it was a countrywide attack pinning the valid cert wouldn't be very effective if the browser has never been to your site before.
Because then you're stuck using that country's CAs, and so you can't pin the root or intermediate certs without giving them the keys. You could pin your cert, but that has other disadvantages.
> 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.
I'd love to hear more about this. How would it work?
Lets Encrypt gets a lot of flack because their certs need to renew every three months. I can't imagine why bad actors wouldn't immediately try to swamp any system of revocation with requests.
Imagine a new flag for certificates issued by CAs that support CT, indicating that the domain owner (e.g. github.com) intends to continue to only use CT-capable authorities.
Any certificate issued for e.g. github.com by any other CA immediately become evidence of malicious conduct attributable directly to that CA, and grounds for automated revocation of trust.
I'm not sure what the lifetime of Let's Encrypt certs has to do with this. I'm also not certain how the bad actors would exploit this process, can you explain?
Chrome is experimenting with something called Expect-CT[1], which allows site operators to indicate that only certificates with valid SCTs should be trusted. The implementation is quite similar to HSTS. It's report-only for now, but will probably evolve to something like Require-CT (i.e. CT enforcement) in the future.
Sounds like the right way to go. Thanks for the pointer.
As these things develop and become increasingly security-critical parts of the protocol, it would be nice if programs like libcurl and other HTTP client libraries gained support for them.
You need the CA to either have been cooperating with CT all along, or have kept a copy of all the certs it ever issued, neither of which an incompetent CA is likely to have done.
But Google did require them to use CT for all new certificates, which I think they are enforcing by assuming Symantec won't lie about the issuance date of new certs.
You may not be able to immediately spot a bad CA, but the more major CAs buy in to CT, the easier it is to spot fraudulent certs through fingerprint reporting. SSL clients can then choose to have a side-channel trust revocation mechanism. Once adoption snowballs, the overall level of trust in the system will rise.
The other problem is that CAs need to be regionally confined in which TLD CNs they can issue certs for.
There are some good arguments in both directions on that thread. I do happen to like the world in which, say, Let's Encrypt is capable of issuing for any TLD. If we don't think WoSign is good enough for signing .com, we probably shouldn't be exposing .cn users to those attacks, either.
I find the arguments from "it's wrong to recognize borders on the Internet" a bit naive, or impractical. The borders recognize us, and state-sponsored attacks will continue, and have very far-reaching implications. We need better tools to fight them, including this one.
I like the discussion in that thread about how to make the scheme reasonably flexible, though. Thanks for the link.
> if you don't punish ... ppl who don't do research first, things will deteriorate rapidly.
Is there a way customers would have or could have known beforehand that this CA was fishy? I agree that the CA should be punished/ostracized, but it isn't obvious to me that most of its customers would have known they were a fishy CA.
" 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 "
Politicians in the US and UK have also claimed they want to ban encryption. Unless the CA is literally run by the government (which some Chinese CAs are, but not this one), it doesn't make sense to penalize them for dumb things their country's politicians say.
I wouldn't say it's out of context, I was clearly stating my worries when this CA was discussed here a couple of years ago.
I think something should be done, but it's not my call of course. Given we do have Let's Encrypt now, I wouldn't feel in the least bit sad in revoking the WoSign certs. Anyone affected can, and should, change.
It's disappointing to see my concerns back then were well-placed, and there are clear indications StartCom's and WoSign's backends are connected together somehow?! I don't know what's going on there exactly, and someone should definitely find out.
In July 2016, it became clear that there was some problems with the
StartEncrypt automatic issuance service recently deployed by the CA
StartCom. As well as other problems it had, which are outside the scope
of this discussion, changing a simple API parameter in the POST request
on the submission page changed the root certificate to which the
resulting certificate chained up. The value "2" made a certificate
signed by "StartCom Class 1 DV Server CA", "1" selected "WoSign CA Free
SSL Certificate G2" and "0" selected "CA 沃通根证书", another root
certificate owned by WoSign and trusted by Firefox.
Using the value "1" led to a certificate which had a notBefore date
(usage start date) of 20th December 2015, and which was signed using the
SHA-1 checksum algorithm.
* The issuance of certificates using SHA-1 has been banned by the
Baseline Requirements since January 1st, 2016. Browsers, including
Firefox, planned to enforce this[2] by not trusting certs with a
notBefore date after that date, but in the case of Firefox the fix had
to be backed out due to web compatibility issues. However, we are
considering how/when to reintroduce it, and CAs presumably know this.
* The issuance of backdated certificates is not forbidden, but is listed
in Mozilla's list of Problematic Practices[3]. It says "Minor tweaking
for technical compatibility reasons is accepted, but backdating
certificates in order to avoid some deadline or code-enforced
restriction is not."
* WoSign deny that their code backdated the certificates in order to
avoid browser-based restrictions - they say "this date is the day we
stop to use this code"[4]. If that is true, it is not clear to us how
StartCom came to deploy WoSign code that WoSign itself had abandoned.
* It seems clear from publicly available information that StartCom's
issuance systems are linked to WoSign's issuance systems in some way.
Nevertheless, it should not have been possible for an application for a
cert from StartCom to produce a cert signed by WoSign.
* This misissuance incident was not reported to Mozilla by WoSign as it
should have been.
> 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.
Amateur hour. You'd think understanding the rules of the game would be a prerequisite to be a warden of the entire TLS ecosystem, as any unrestricted CA is.
It's not comforting that the entire security of https globally is now in the hands of someone unable to read the CA requirements, and doesn't even seem to worry about that fact.
But prior to March 2015, CAs could issue certs valid for up to 5 years. So even if browsers stopped accepting WoSign certs with an issuance date after today, WoSign could still issue certs "issued March 2015 valid until to March 2020" and browsers would accept them.
If they start putting fake dates on the certs then the nuclear option is the only option. They are in the business of selling trust and they're outright lying on their only product? That's untenable.
Maybe the best would be to build a whitelist of WoSign certs then, scrap it from the publicly available websites and allow people to submit their own. Then some kind of bloom filter could do the trick I guess.
Trust of a CA doesn't have to be binary - it could be stochastic.
Let's say that when a browser wishes to revoke a CA certificate, it chooses a timeframe for a "deprecation period". Before the deprecation period, the CA is fully trusted. After the deprecation period, it has been completely eliminated.
During the deprecation period, a browser will possibly pop up an error page rather than accepting the certificate. The probability of this happening increases as the deprecation period advances, slowly "turning up the pain" (likely exponentially or quadratically, for slow initial growth).
A reload will clear the error and load the page (or perhaps go through the probability again). Obviously it would be good if the site were notified through a header that this was happening. And user feedback will accomplish the same thing in a cruder manner.
Proactive sites would move off before the deprecation period even began. Less connected sites would get user reports and move off early in the period. Negligent sites would see their users migrate to different sites as their functionality got ever worse.
Would that not just encourage your average user to click through the security warnings and ignore them, potentially numbing them to other more important warnings?
Users aren't the ones who should feel the pain of a rogue CA, we need the CA to feel the pain somehow.
Perhaps it'd be better as a series of progressive informational pages than described in terms of certificate rejection. The central idea is that the site will become gradually less usable.
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.
Their punishment would be having to pay for another certificate and install it and using a more reputable one and not necessarily the cheapest one around next time. I think in this case the punishment fits the crime perfectly.
more reputable one and not necessarily the cheapest one
The two don't seem to be linked at all; Symantec's cheapest cert (non-EV, no-wildcard) costs $399 - almost 80x the cheapest ones - and yet they were caught issuing unauthorized certs.
Oh, of course, expensive doesn't mean good. Maybe the cheapest one is the best one. I'm just saying the reputation should be a primary consideration, or at least one of. There should be consequences for bad behavior for CA vendors.
Give them a month, publicize in the relevant places, and that's that. If a site gets caught out it's not the end of the world. If they have big money on the line then they can afford to have someone on staff that keeps up with this stuff.
Yikes. If all of that is true, surely Google will permanently ban WoSign from Chrome? And I would hope Mozilla and Microsoft, too, but Google is usually the one to "play tough" with rogue CAs (and I hope they will strive to develop and maintain that reputation).
> Yikes. If all of that is true, surely Google will permanently ban WoSign from Chrome? And I would hope Mozilla and Microsoft, too, but Google is usually the one to "play tough" with rogue CAs (and I hope they will strive to develop and maintain that reputation).
This will most likely happen, because a) the CA is not a western CA and b) it was due to incompetence.
If they had been competent but intentionally and willfully broken the trust of the CA system, assuming they had enough money, they would keep their CA cert. Case in point: TrustWave still has their CA certificate after intentionally selling sub-CAs for the purpose of MITM! But don't worry, they promised they'll never to it again, honest.
Wosign is not in the list of default CAs on the Mac, according to Keychain, so if you are using Chrome on a Mac, since Chrome only uses the system's root certs, you should be safe as long as you don't go add that root cert into Keychain. Wosign is in Firefox however, so Mozilla needs to do something about this.
You can add code to fail validation if this specific intermediate certificate is in the trust chain, but there's no way to ban intermediate certificates with the X.509 trust model without removing the root from the CA store.
Firefox/Chrome already do some extra validation to ban SHA1 certs issued past a specific date, they'd just need to blacklist the fingerprint of the intermediate CA.
Just FYI, since you only quoted one certificate. Both GitHub certificates were mine, not just the one. I created a second account for the second certificate.
WoSign was also caught red-handed backdating certificates to avoid the SHA1 deprecation.
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 problem with this approach is that a CA that's been given the death penalty has little to lose, so they might just start backdating certificates. In fact, backdating SHA-1 certificates is one of the incidents they've now reported.
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).
but you have to code that in every browser and hope people will be able to patch up. a revocation list from parent certificate company nuking the ca is the intended way to deal with trust breach, it should be supported everywhere, and doesn't require a full redeployment of browsers (And sometime entire OSes!) across the world.
Most major (non-embedded, I suppose) OSes have some framework for periodically updating the certificate store. It's not necessarily a full redeployment of the OS.
Mac OS and Windows both are capable of receiving new root certs via the OS update process. Apple says it updates certs approximately once per quarter:
I think there is a pretty strong argument for treating a bad CA like a zero-day vulnerability and "fixing" the problem through a security update that un-trusts the cert. However, to date neither Apple nor Microsoft have been especially aggressive in this regard.
Google has taken a somewhat freer hand towards badly-behaved CAs, but they really only control Android: Chrome uses the OS's trust store, rather than its own (as Firefox does). They could presumably change this, and I'm sometimes unsure why they don't, but I guess it has to do with enterprise-environment interoperability. At some point if Chrome were to become the dominant browser, such that they could dictate terms to enterprise customers rather than the other way around (or if web apps really did take over the world to the point where the keystore outside your browser is essentially irrelevant; cf. Chromebooks), maybe they would reconsider this decision...
While Chrome technically does not have the kind of root program that other OS or browser vendors run, they have the ability to revoke trust for specific roots, plus other things, like enforcing CT for specific CAs. Given that there's already a root program that's being run transparently, there's not that big of an incentive to run yet another root program, IMO. Plus, while I'm extremely happy that Mozilla is running their own root program for various reasons, using existing OS APIs for these things seems like the cleanest approach (if you can't trust your OS to make these decisions, you probably have bigger problems and shouldn't run that OS anyway).
This is a pretty misleading title for a couple of reasons:
1) WoSign may face revocation (I doubt it but I don't know), but there is no evidence of that in this article. This is just one person not affiliated with a root program "calling for" it. People on the internet call for revocation of major CA roots all the time.
2) I don't really know what a "fake" cert is, it's a very strange choice of words. I would think a fake cert is not a real cert, and in that case issuing fake certs is fine because browsers won't trust them. It seems the problem here is that real certs were issued when they shouldn't have been. That's called "mis-issuance", not "fake certs."
You are just being pedantic. The meaning is perfectly clear, they are creating certificates for a domain and giving them to people who do not control/own that domain. Pick whatever word you like to describe this. The story is very clear.
Too big to fail my ass. There's no such thing when it comes to security. If anything, that's more reason to cut them loose.
If a CA pulls shit like this they need to be revoked immediately and let the wrath of 1000s of businesses that are impacted by cert warnings rain down upon them. That will 1) Solve the security problem immediately and 2) Publicize what it means to get a cert from a crap CA that doesn't care about security.
Sure it will suck for the "little guy" who didn't know but, if you don't do this, he'll never know and never learn.
> I won't comment on the specifics of this case, but a more nuanced approach regarding security is preferable because it favours transparency.
Certificate Transparency solves a lot of this already. It'd be nice if you could flag your domain as being only acceptable from a CA of your choosing. I don't even think the false positives would be an issue as worst case you have security conscious customers not coming to your site (i.e. you make the business decision).
> If a vendor/CA/whatever knows that they will die if anything comes out, they will bury things like this even deeper.
There's already ways to handle this. 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. The intermediate certificates would be rolled over every N days and creation of new ones should happen offline (i.e. where you keep your master CA cert, the "approved" one).
If you have a system like that in place before shit hits the fan, the damage is isolated to the impacted intermediate certs which could be selectively revoked/blacklisted. If a CQ has not taken those precautions then they've got no recourse when something like this happens.
From a user's perspective, I wouldn't want my browser/OS/app to trust any certificates from these losers. If they can't isolate the damage that's their and their customer's problem. I'm not going to compromise my security for their sake.
> It'd be nice if you could flag your domain as being only acceptable from a CA of your choosing.
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.
The root certificates trusted by Windows are fetched from Microsoft's servers as needed. You can download all of them using the command:
certutil -generateSSTFromWU roots.sst
Then if you open up roots.sst (it opens in certmgr.msc) and sort by Friendly Name, you should see the WoSign roots. You can then export these and import them into the Untrusted Certificates store if you wish to block WoSign as a trusted root.
So what's the relation to StartCom/StartSSL? I remember reading some comments about half a year ago mentioning that the startssl website suddenly was hosted on Chinese IP addresses, just around the time they redesigned the web page. This seemed fishy enough back then that I finally switched from startssl to letsencrypt for non-wildcard certs and actually started paying a different CA for wildcart certs...
Did the StartSSL root CA change hands / was it sold to a Chinese company (Wosign?)
I seem to remember the CEO used to be vocal in various ssl and ca forums and on bugzilla earlier.... But no comments lately?
From what I've seen earlier, he's appeared to have a clue or two about SSL. I wonder what's going on with wosign+startssl despite that? Isn't it all very related?
This came up on the Mozilla mailing list and the most likely explanation is that they're sharing some infrastructure, i.e. one CA is hosting the other[1]. This is apparently quite common in the industry.
I don't think the Baseline Requirements (or any of the root program policies) currently require that CAs disclose these arrangements. I don't think CA hosting is inherently bad (in many cases I'd actually be happy to know that a CA is not running their own infrastructure), but it would probably be a good idea to force CAs to be transparent about it. If it's publicly known that WoSign and StartCom use the same domain validation infrastructure (just as an example, this might not be the case), that fact would be highly relevant for this discussion.
Can't browsers at least restrict CAs like WoSign so that their roots are only accepted for .cn domains?
I realize that X.509 name constraints are utterly broken, but that doesn't mean that browsers can't manually restrict the domains that a given root is accepted for.
Is there an easy way for me to revoke trust from all Chinese CAs? Anyone in China is ultimately subject to being forced to do the dirty work of the Chinese Communist Party. Why are browser and OS vendors even trusting them in the first place?
I untrusted all Chinese-sounding CAs from "System Roots" under "Keychain Access" in OSX as soon as I got my laptop. That's what Chrome and Safari verify against.
That wouldn't have helped you in this case -- WoSign doesn't even show up in the OS X or Windows root keystores. Its certificates are (apparently) signed by StartCom.
I just blacklisted StartCom's root certs. IMO for signing off on WoSign they're just as guilty, if not worse, than WoSign itself. Since they're the ones with the root cert in the OS, the buck stops there.
I attempted to remove all StartCom certs from the OS X keychain, apparently you can't do it even as root. You have to boot into the recovery partition first.
I can't remember whether it was MacOS or Windows, but at least one OS will sometimes re-install a 'standard' CA certificate if you delete it. Setting 'never trust' is the most reliable way to kick out the CA as it ensures that it stays out.
Partial solutions include blocking the CA's certs based on the issuance date or insisting they hand over a list of the certs they've issued - but if the CA is going down in flames anyway, they have no incentive to cooperate; they can backdate certs and destroy their own customer list.
My theory is [1] this is one of the side benefits of Certificate Transparency - CT will give browser vendors a list of certs to grandfather in if they decide to shut down a CA against its will.
[1] https://www.mjt.me.uk/posts/certificate-transparency/