Answer this question: Where did the root certificates in your Web browser, computer or mobile device come from, and why do you trust them? It's a question I like to ask my students in the grad course I teach at Syracuse University because there is an inordinate amount of trust in all things SSL/TLS and the Golden Lock. (Don't get me going on that farce called Extended Validation Certificates.) The SSL/TLS protocol and the public key cryptography that underpins it are, as far as I know, well-designed and trustworthy. Barring software vulnerabilities and poorly designed SSL/TLS libraries, such as the Python SSL library's default implicit trust of certificates that Brian Keefer points out in Unauthenticated SSL Sends a Dangerous Message, we can trust the protocol and the math.
No, the trust lies with CAs such as Comodo and Verisign that issue, manage and revoke certificates. Everyone knows the name Verisign. Some may also know Comodo or Thawte (acquired by Verisign in 1999). But there are many, many other players, and the merger and acquisition activity among them is worthy of any shell game on the street. Here's a head scratcher: Who owns and runs the GTE Cybertrust Root CA? GTE hasn't run that CA in more than 11 years. Did you know the GTE Cybertrust CA was acquired by Baltimore Technologies in 2000? Baltimore sold off the CA to BeTrusted Holdings in 2003. BeTrusted and TruSecure merged, forming Cybertrust, in 2004. Cybertrust was then acquired by Verizon business in 2007.
What about some other trusted authorities? If you like football, you probably know who GoDaddy.com is. Did you know it runs a CA? So does the Taiwan Government, as well as Dell. Why would you trust any of them?
I am not saying any of those vendors should or should not be trusted. In fact, I am not saying anything about them at all, really. I am asking why you and your organization would trust them? Have you contacted any of them? Have you negotiated contract terms and signed the papers? Have you ensured that they are running their CA properly and up to your organization's standards? The answer to all of those questions is probably no. You could go read their certification practice statement, which defines how they run their CA and other components. You could also go read their certificate policies, which state the acceptable uses of the certificates, how they are issued and other things. One or the other describe the CA's self-stated role and responsibilities, as well as any redress in the case of a problem with a certificate they issued.