How feasible is it for a CA to be hacked? Which default trusted root certificates should I remove?

Update 5 The root problem (heh) with the CA model is that in general practice, any CA can issue certs for any domain, so you're vulnerable to the weakest link. As to who you can trust, I doubt that the list is very long at all, since the stakes are high and security is hard. I recommend Christopher Soghoian's post on the subject, which clarifies the various approaches that governments around the world have used to get access to private user data - whether by directly demanding it from companies that operate cloud services, via wiretap, or increasingly now via CA coercion or hacks: slight paranoia: The forces that led to the DigiNotar hack.

Here I provide some specifics, and end with links to some potential fixes.

In 2009, Etisalat (60% owned by the United Arab Emirates government), rolled out an innocuous looking BlackBerry patch that inserted spyware into RIM devices, enabling monitoring of e-mail, so it can hardly be considered trustworthy. But it is in a lot of trusted CA lists: http://arstechnica.com/business/news/2009/07/mobile-carrier-rolls-out-spyware-as-a-3g-update.ars

Update 1 See also an example of a successful attack, allegedly by an Iranian named ComodoHacker, against Comodo: Rogue SSL certificates ("case comodogate") - F-Secure Weblog. F-Secure notes that Mozilla includes certificates issued by CAs in China, Israel, Bermuda, South Africa, Estonia, Romania, Slovakia, Spain, Norway, Colombia, France, Taiwan, UK, The Netherlands, Turkey, USA, Hong Kong, Japan, Hungary, Germany and Switzerland.

Tunisia is another country that runs a widely-trusted CA, and there is also good documentation of the actions of their government to invade privacy: The Inside Story of How Facebook Responded to Tunisian Hacks - Alexis Madrigal - Technology - The Atlantic

Mozilla notes another questionable practice to watch out for: CAs that allow an RA partner to issue certs directly off the root, rather than via an intermediary: Comodo Certificate Issue – Follow Up at Mozilla Security Blog.
See also more detail, including speculation about the claim of responsibility by a lone Iranian hacker Web Browsers and Comodo Disclose A Successful Certificate Authority Attack, Perhaps From Iran | Freedom to Tinker

Update 3: Another successful attack seemingly also by ComodoHacker was against the DigiNotar CA. Their website was compromised starting in 2009, but this was not noticed until after DigiNotar had also been used in 2011 by Iranians to sign false certificates for the websites of Google, Yahoo!, Mozilla, WordPress and The Tor Project. DigiNotar did not reveal its knowledge of the intrusion into its site for over a month. See more at DigiNotar Hack Highlights the Critical Failures of our SSL Web Security Model | Freedom to Tinker.

I'd guess that the range of vulnerability of various CAs varies pretty widely, as does their utility. So I'd suggest refocusing your strategy. When you can narrow it to specific assets you're trying to protect, just delete all CAs except those necessary for using those assets. Otherwise, consider eliminating the CAs you judge to be most vulnerable to those who care about your assets, or least popular, just to reduce the attack surface. But accept the fact that you'll remain vulnerable to sophisticated attacks even against the most popular and careful CAs.

Update 2: There is a great post on fixing our dangerous CA infrastructure at Freedom to Tinker: Building a better CA infrastructure

It talks about these innovations:

  • ImperialViolet - DNSSEC and TLS

  • Network Notary - Perspectives : Improving SSH-style Host Authentication with Multi-path Network Probing

  • Google Online Security Blog: Improving SSL certificate security

Update 4 One of our IT Security blog posts in August 2011 also covers the case for moving to DNSSEC: A Risk-Based Look at Fixing the Certificate Authority Problem « Stack Exchange Security Blog

Update 6 Several Certificate Authorities have been caught violating the rules. That includes the French cyberdefense agency (ANSSI), and Trustwave, each of which was linked to spoofing of digital certificates.

Update 7 Yet another set of "misissued certificates", via the Indian Controller of Certifying Authorities (India CCA) in 2014: Google Online Security Blog: Maintaining digital certificate security

See also the question on Certificate Transparency which looks like a helpful approach to discovering bad certificates and policy violations earlier.


As Matt Blaze once wrote, CAs protect you from anyone who they are unwilling to take money from. That should tell you something about where the CA's incentives lie, and some potential risks in the arrangement.


I'm afraid that the short answer to this question is that it's impossible to know, as far as I can see. There are a large number of default CA's installed in most common browsers and assessing how likely they are to be "trustworthy" in terms of giving out certificates to governmental or other organisation is difficult.

If a CA became known as untrustworthy then they would likely be removed from browsers default installation lists, (per @xce below, Diginotar is a good example here and also Digicert)

In addition to the organisation providing certificates voluntarily, there's the risk that they may provide certificates without making appropriate security checks on the requestor. At Defcon a couple of years back there were several presentations on this theme of being able to get certificates without authorisation.

If this is a significant concern, the only way I can think of to go would be to create a white-list of CAs that you've reviewed and are comfortable with the security provided. Obviously this wouldn't work for accessing the general Internet as you'd likely end up removing CAs who have issues Certs to sites that you'd like to use.