JSSE introduces the notion of a truststore, which is a database that holds certificates. In fact, a truststore has exactly the same format as a keystore; both are administered with keytool, and both are represented programmatically as instances of the KeyStore class. The difference between a keystore and a truststore is more a matter of function than of programming construct, as we will see.
The server in an SSL conversation must have a private key and a certificate that verifies its identity. The private key is used by the server as part of the key exchange algorithm, and the certificate is sent to the client to tell the client who the server is. This information is obtained from the keystore. Remember that the private key is never sent from the server to the client; it is used only as an input to the key exchange algorithm.
SSL servers can require that the client authenticate itself as well. In that case, the client must have its own keystore with a private key and certificate.
The truststore is used by the client to verify the certificate that is sent by the server. If I set up an SSL server, it will use a certificate from my keystore to vouch for my identity. This certificate is signed by a trusted certificate authority (or, as we've seen, there may be a chain of certificates, the last of which is signed by a recognized CA). When your SSL client receives my certificate, it must verify that certificate, which means that the trusted CA's certificate must be in your local truststore. In general, all SSL clients must have a truststore. If an SSL server requires client authentication, it must also have a truststore.
In sum, keystores are used to provide credentials, while truststores are used to verify credentials. Servers use keystores to obtain the certificates they present to the clients; clients use truststores to obtain root certificates in order to verify the servers' certificates.
The keystore and truststore can be (and often are) the same file. However, it's usually easier to manage keys if they are separate: the truststore can contain the public certificates of trusted CAs and can be shared easily, while the keystore can contain the private key and certificate of the local organization and can be stored in a protected location. In addition, JSSE is easier to use if the keystore contains a single alias. When the keystore contains multiple aliases there are ways to specify which one should be used, but that requires more programming. Keep in mind that in general a keystore containing a single alias makes using JSSE simpler.
A keystore contains private keys, and the certificates with their corresponding public keys. You only need this if you are a server, or if the server requires client authentication.
A truststore contains certificates from other parties that you expect to communicate with, or from Certificate Authorities that you trust to identify other parties. If your server’s certificate is signed by a recognized CA, the default truststore that ships with the JR will already trust it (because it already trusts trustworthy CAs), so you don’t need to build your own, or to add anything to the one from the JRE.
Wednesday, November 11, 2009
keyStore vs trustStore
Basically they can be a single store or separate.
You will store in Keystore normally your private stuff and have a different store of trusted entries.
The separation is good idea.
The keystore will be used for encrypting/signing some thing with your private key while the trust stores will be used mostly to authenticate remote servers etc.
In java I think to trust any entries you will pass -trustcacerts option.
You always need a truststore that points to a file containing trusted certificates, no matter whether you are implementing the server or the client side of the protocol, with one exception. This file is often has a name like cacerts, and by default it may turn out to be a file named cacerts in your jre security directory. The filenames you gave are not defaults, so their contents are not obvious to me.
You may or may not need a keystore. The keystore points to a file containing private key material. You need a keystore if:
1) you are implementing the server side of the protocol, or
2) you are implementing the client side and you need to authenticate yourself to the server.
There is one exception to everything stated. If you are using certain anonymous DH ciphersuites, then neither side needs either a truststore or a keystore. The connection is unauthenticated.
You will store in Keystore normally your private stuff and have a different store of trusted entries.
The separation is good idea.
The keystore will be used for encrypting/signing some thing with your private key while the trust stores will be used mostly to authenticate remote servers etc.
In java I think to trust any entries you will pass -trustcacerts option.
You always need a truststore that points to a file containing trusted certificates, no matter whether you are implementing the server or the client side of the protocol, with one exception. This file is often has a name like cacerts, and by default it may turn out to be a file named cacerts in your jre security directory. The filenames you gave are not defaults, so their contents are not obvious to me.
You may or may not need a keystore. The keystore points to a file containing private key material. You need a keystore if:
1) you are implementing the server side of the protocol, or
2) you are implementing the client side and you need to authenticate yourself to the server.
There is one exception to everything stated. If you are using certain anonymous DH ciphersuites, then neither side needs either a truststore or a keystore. The connection is unauthenticated.
Subscribe to:
Posts (Atom)