Keystore content

Cryptography objects like a private key and certificates are stored in individual SafeBag containers within a PKCS #12 keystore file. Normally, at least the SafeBag containing a private key is encrypted using a PBE (password based encryption) method. The keystore file itself also can be encrypted, usually with the same password. With that, access to all content in a PKCS #12 keystore is secured with a password.

The Safebag containers can have several attributes. The most commonly used SafeBag attributes are a Friendly Name and a Key ID. These are used to identify the objects in the keystore and relate them to each other, as explained below. Especially the more human readable Friendly Name is useful for managing the objects in a keystore.

For TLS communications, the keystore of a server contains just one private key. And for a private key in a keystore, there also must be the corresponding user certificate with the public key of the key pair. The private key and the corresponding user certificate are stored in different SafeBags, because at least the SafeBag with the private key is encrypted. As the certificate is used publicly, the SafeBag containing it normally is not encrypted. The relation between the private key and the corresponding user certificate in their individual SafeBags is realized by both SafeBags having the same Friendly Name and the same Key ID attributes. The Friendly Name makes it also easy for an administrator to understand, which is the user certificate corresponding to the private key in a keystore.

Besides the private key and the corresponding user certificate, the keystore may contain additional certificates. These are then considered CA certificates. They could be the CA certificates from the certificate chain used for signing the server's user certificate, but could just as well be completely unrelated CA certificates. For a server it is normally sufficient to have its private key and the corresponding user certificate in the keystore. CA certificates can be present, but are not needed, because the server normally does not authenticate the client. For a client, the CA certificate(s) needed to authenticate the server must be in the keystore. The client does not need a private key and therefore also has no user certificate.

Client authentication during the TLS handshake is a seldom used option of the TLS protocol. If activated, the server asks the client for its own user certificate, sometimes also called client certificate. In this case, the client has its own private key and the corresponding user certificate in its keystore, and sends this user certificate to the server to fulfill the server's request. The server in turn needs the proper CA certificate(s) in its own keystore, so that it can use them to authenticate the client. These CA certificates are from the certificate chain that was used to issue and sign the client's user certificate. Often, both user certificates, the server's as well as the client's, are issued and signed by the same CA(s). Then the CA certificates in both keystores are the same. However, this is not a requirement.The user certificates of server and client can just as well be issued by different CAs.