Need help setting up a truststore's chain of authority (in Tomcat)

Lead in ... I'm not an expert, by far, in application security via SSL, but am trying to establish a test environment that includes all possible scenarios we may encounter in production. For this I have a tree of Certificate Authorities (CAs) that are the issuers of an assortment of test client certificates, and node/server certificates (complex test environment representing the various published web services and other applications we integrate with).

The structure of these CAs are as follows: Root CA, which has signed/issued Sub CA1, Sub CA2, and Sub CA3. These subs have then signed/issued all certificates of those various nodes and clients in the environment.

Now for the question开发者_如何学编程 .... In my application's truststore I would like to trust everything signed by Sub CA1, and Sub CA2, but not Sub CA3 (untrusted). Does this mean my truststore should (1) ONLY include Sub CA1 and Sub CA2, or (2) should it include Root CA, Sub CA1, and Sub CA2?

I don't know what is the proper way to represent this trust chain in a truststore. In the future I would also like to add a Sub CA4 (also signed/issued by the Root CA), but add that to a Certificate Revocation List (CRL) for testing purposes.

Ahead of time, thank you for any help concerning this. It's greatly appreciated.

CAVEAT: I'm not going to test this so I hope my answer is correct.

I think your basic assumption is correct. I don't believe you can selectively revoke trust without writing custom code, so your truststore should only contain certificates who are trusted completely. So leave the root CA out and choose your option (1).

As you can see, trying to enforce such fine grained access control is ill-suited to the Java (and most every other system's) X509 certificate -based authentication model. They are basically designed to outsource identity verification to Verisign, Thawte, GoDaddy, GlobalSign, etc. for SSL certificates and code signing certificates. It can support other models, including self-signed certificates, but not without considerable up-front pain and ongoing maintenance headaches.