Skip to content

Trusted store vs keystore

October 10, 2012
tags: ,

From SO site:

both javax.net.ssl.keyStore and javax.net.ssl.trustStore are used to specify which keystores to use, for two different purposes. Keystores come in various formats and are not even necessarily files (see this question), and keytoolis just a tool to perform various operations on them (import/export/list/…).

The javax.net.ssl.keyStore and javax.net.ssl.trustStore parameters are the default parameters used to build KeyManagers and TrustManagers (respectively), then used to build an SSLContext which essentially contains the SSL/TLS settings to use when making an SSL/TLS connection via an SSLSocketFactory or an SSLEngine. These system properties are just where the default values come from, which is then used by SSLContext.getDefault(), itself used by SSLSocketFactory.getDefault() for example. (All of this can be customized via the API in a number of places, if you’re don’t want to used the default values and what specific SSLContexts for a given purpose.)

The difference between the KeyManager and TrustManager (and thus between javax.net.ssl.keyStore and javax.net.ssl.trustStore) is as follows (quoted from the JSSE ref guide):

TrustManager: Determines whether the remote authentication credentials (and thus the connection) should be trusted.

KeyManager: Determines which authentication credentials to send to the remote host.

(Other parameters are available and their default values are described in the JSSE ref guide. Note that while there is a default value for the trust store, there isn’t one for the key store.)

Essentially, the keystore in javax.net.ssl.keyStore is meant to contain your private keys and certificates, whereas the javax.net.ssl.trustStore is meant to contain the CA certificates you’re willing to trust when a remote party presents its certificate. In some cases, they can be one and the same store, although it’s often better practice to use distinct stores (especially when they’re file-based).

You don’t need to specify a truststore, because there’s a default value for it (it’s bundled with the JRE), usually in $JAVA_HOME/lib/security/cacerts (see 2nd JSSE ref guide link I sent). Like browsers, it contains a default set of trusted CA certificates. In general, a client will always use a truststore to check the server cert but the keystore will only be used if the server requests a client cert, and the server will always use a keystore for its own key+cert but the truststore will only be used if the client sends a client certificate. –
= = = = = = = = = =

The keystore file generated by Keytool stores pairs of private and public keys. Each pair or entry stored in the keystore is refered by a unique alias. In brief:

Keystore entry = private + public key pair = identified by an alias

The keystore protects each private key with its individual password, and also protects the integrity of the entire keystore with a (possibly different) password.

For instnace, when you sign an Android application using the Export Signed Application Package option of the Eclipse Android tool, you are asked to select a keystore first, and then asked to select a single alias/entry/pair from that keystore. After providing the passwords for both the keystore and the chosen alias, the app is signed and the public key (the certificate) for that alias is embedded into the APK.

Now to answer your question, you can only release an update to an application that was signed with the alias ‘foo’ by signing the update again with the same alias. Losing the keystore where your alias is stored would prevent you from releasing an updated version of your app.

There is however a way to sign an app with a new alias, but it involves cloning an existing alias in the keystore using keytool -keyclone:

Creates a new keystore entry, which has the same private key and certificate chain as the original entry.

The original entry is identified by alias (which defaults to “mykey” if not provided). The new (destination) entry is identified by dest_alias. If no destination alias is supplied at the command line, the user is prompted for it.

If the private key password is different from the keystore password, then the entry will only be cloned if a valid keypass is supplied. This is the password used to protect the private key associated with alias. If no key password is supplied at the command line, and the private key password is different from the keystore password, the user is prompted for it. The private key in the cloned entry may be protected with a different password, if desired. If no -new option is supplied at the command line, the user is prompted for the new entry’s password (and may choose to let it be the same as for the cloned entry’s private key).

Advertisements
One Comment leave one →
  1. October 14, 2014 5:48 am

    Thanks, nice post

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: