Why does Apple include 5 COMODO root certs in OS X? There's "AddTrust {Class 1, External, Public, Qualified} CA Root" and also "COMODO Root Certificate".

Why isn't one enough, if it's owned by a company?

  • I imagine that it might be a cross-root certificate. When a new CA enters the market they have their CA-cert signed by another, older, more well established CA. This means that existing clients that trust the old CA will also trust the new CA. And over time as device trust stores are updated they will eventually trust the new CA as well. -- But I don't know if that is really the case here. Just sounds plausible. Jul 21 '15 at 13:14
  • If I am understanding those certs correctly, the COMODO Root Certificate that's in OS X is subordinate to the AddTrust External CA Root, meaning that OS X will not trust any of the certs that they have sold. Is that correct? Jul 21 '15 at 15:20
  • Could you edit your question to provide more detail about which part you find odd? Jul 21 '15 at 15:22
  • 1
    @AndreyFedorov Are you sure that "AddTrust" isn't just what COMODO calls its CA? This link describes the "Addtrust External CA Root" as "Comodo root used for Comodo range of products." and the AddTrust CA publishes its Revocation list to crl.comodoca.com/AddTrustExternalCARoot.crl . . . It seems to me like AddTrust and COMODO are the same thing. Jul 21 '15 at 19:35
  • 1
    Andrey, That was meant as a joke. See en.wikipedia.org/wiki/Comodo_Group#Certificate_hacking
    – mti2935
    Jul 22 '15 at 23:49

In my browser (Chrome on Windows) I have certs for both of those CAs. I'm not entirely sure what your question is getting at (Why a CA would have more than one cert? Why a CA would issue off a non-root cert? Why OS X doesn't ship with the root cert?). If you could update your question with more detail, that would be great, but in the meantime I'll try to answer the most general question.

Why a CA would issue off a non-root certificate?

It is very common for a public CA to use a non-root CA for issuing customer certificates. As far as establishing trust, it only matters that the customer certs can chain back to the root that's in your browser, which intermediate CA actually issued it is mostly irrelevant.

There are a number of reasons for setting up a CA hierarchy like this, some are security-related, some are IT-related. Let's look at an example CA setup (not the best image, but let's go with it):

CA Hierarchy

Reasons that you might want to set it up this way:

IT / Administrative

A CA may have multiple marketing departments that all issue SSL certs. Maybe these departments are in different physical locations, maybe they're subject to subject to different laws, or maybe they're just in different departments of the company. Either way you probably want the admins for each department to not have access to the CA for other departments.


What happens if your Root CA gets compromised? How do you recover from that? You don't, your company goes bankrupt, it's happened before.

If instead, it's a intermediate CA that gets compromised you have options. If each intermediate CA is on a different network with different admins then chance are good that you can shut it down without compromising any other CAs. You have to be careful with both the technical and PR aspects, but it's possible to move customer certs on the compromised CA over to another CA without people losing trust in you. It's not easy, but you have options.

Offline Root CA

For these reasons it's common for commercial CAs to have their root be a machine that is never, at any point, connected to a network. Its only job in life is to issue certificates for the CAs immediately below it, then you turn it off and put it in a vault. Good luck hacking into that.

My guess from looking at those two certs you linked is that

C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root

is an offline root, and

C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO Certification Authority

(which is subordinate to the first one) is a regional departmental CA (though clarification of your question would help).

  • 2
    The "Offline Root CA" is a bit incorrect. These days, it's never housed on a single server, rather it is split into many keys given to numerous lawyers, corporate officers etc that would have to come together to again sign anything with the key. Intermediate certificates are always used by commercial CAs to issue certificates. en.wikipedia.org/wiki/Key_Ceremony Jul 21 '15 at 18:11
  • 1
    @Herringbone_Cat Umm, yes you can break the root private key into multiple chunks and store the chunks separately with different people, etc. My point was that once the Root has issued some certs, you shut it down and lock it up. Being more careful about how you "lock it up" doesn't seem to invalidate my point, unless I'm missing something. Jul 21 '15 at 21:06
  • 1
    In order to be SAS70/SSAE16 certified (like every commercial CA trusted by browsers) you have to go through a key ceremony. So, "have their root be a machine that is never at any point connected to a network" describes a single server which has the root key, which is never the case. Thus, it's an inaccurate picture that is drawn. While your point is that the root CA is offline, I think you missed the mark on what that exactly entails; so I thought a comment to be appropriate. Jul 21 '15 at 21:31
  • Cool, I'll be happy to amend it (or feel free to suggest an edit), but I still don't understand your objection (maybe I'm out to lunch?). At the point in time when the Root issues certs for its subordinates, the CA is running on a single machine, and it has access to the entire signing key. Clearly stuff happens before that, and stuff will happen after it, but I don't see why a Key Ceremony makes that wrong. Jul 21 '15 at 22:23
  • 1
    The existence of the key ceremony answers the entire question per se actually about why roots are not used to sign certificates. The key ceremony is FAR more elaborate than having a server sitting in a vault. In fact, a server is never used -- the keys are generated on hardware security modules. Jul 22 '15 at 1:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.