I'm working for a company that sells software products to customers some of which do not have the resources and/or know-how to build and maintain their own CA (used for the SSL communication of our software). In these cases we have to provide the certificates for them. The customers are completely independent and should NOT be able to communicate with each other, i.e. there should be no SSL trust between Customer I and Customer II. I have a rather general question about how to best built such a CA structure. These are the two variations that are currently considered.

Company Root CA with SubCA for each customer:

                    Root CA                  
        /               |              \
       /                |               \
 Customer I     Customer II       Customer III

Independent (Root-)CA for each customer:

 Customer I     Customer II       Customer III

What would be the pros and cons of each variant? Is there an established best practice for such a setup?

  • What exactly is the SSL connection used for? Does the software product authenticate itself against a centralized server at the customer premise? Do you use it for maintenance (i.e. the maintenance server authenticates against the software)? Does the software authenticates itself against a client piece of software? Commented Jun 10, 2014 at 20:04
  • The SSL connection is only used within the client's network. I.e. different sub systems talk to each other but not to us. Commented Jun 17, 2014 at 8:12

2 Answers 2


When people deploy HTTPS Web sites, they often buy "SSL certificates" from commercial CA. Thus, many sites will use certificates issued by the same root CA, and yet they don't trust each other. Same situation here: using a single root will not induce unwanted cross-customer trust relationships.

  • If they all trust the same root CA, they effectively trust each other, don't they? Commented Jun 5, 2014 at 11:22
  • 1
    No. If they all trust the same root CA, then they all trust the root CA. Not each other. That's the whole point. You may make a confusion between having faith in the identification of an entity, and actually trusting what that entity says to you. If the distinction is not clear to you, then keeping all client certificates in separate worlds (your second option) may help you feel safer, though (not being attacked is important, but so is sleeping at night). Commented Jun 5, 2014 at 22:31
  • I understand what you mean, but if I configure the root CA certificate as trust anchor on all the clients and only use SSL Client Auth for authentication then there would be in fact the unwanted cross-customer relationship. I don't know of any way to check for a specific certificate in Tomcat so I effectively trust everything under the configured SSLCACertificateFile. Commented Jun 17, 2014 at 8:16

Use one key for signing your server's certificate and another for signing all your clients. Don't actually have them trust the signer for the cert they are using. It isn't important that the client trust the certificate they are using, it is important that the person they are communicating with (you) does.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .