Identity and Trust Keystores

When you configure SSL, you must decide how identity and trust will be stored. Although one keystore can be used for both identity and trust, Oracle recommends using separate keystores for both identity and trust because the identity keystore (private key/digital certificate pairs) and the trust keystore (trusted CA certificates) may have different security requirements. For example:

  • For trust, you only need the certificates (non-sensitive data) in the keystore. However, for identity, you add the certificate and the private key (sensitive data) in the keystore.
  • The identity keystore may be prohibited by company policy from ever being put on the corporate network, while the trust keystore can be distributed over the network.
  • The identity keystore may be protected by the operating system for both reading and writing by non-authorized users, while the trust keystore only needs to be write protected.
  • The identity keystore password is generally known to fewer people than the password for the trust keystore.

In general, systems within a domain have the same trust rules — they use the same set of trusted CAs — but they tend to have per-server identity. Identity requires a private key, and private keys should not be copied from one system to another. Therefore, you should maintain separate identity keystores for each system, each keystore containing only the server identity needed for that system. However, trust keystores can be copied from system to system, thus making it easier to standardize trust conventions.

Identity is more likely to be stored in hardware keystores such as nCipher. Trust can be stored in a file-based JDK keystore without having security issues because a trust store contains only certificates, not private keys.

Reference: http://docs.oracle.com/cd/E23943_01/web.1111/e13707/identity_trust.htm#SECMG369