KeyManager and TrustManager APIs - J2EE Security for Servlets, EJBs and Web Services: Applying Theory and Standards to Practice

KeyManager and TrustManager APIs

Java SSL library has a flexible mechanism to access externally stored certificates for the purpose of authentication and verification. This mechanism consists of a Key Manager, an instance of a class implementing interface javax.net.ssl.KeyManager, to get the certificate for authentication, and Trust Manager, an instance of a class implementing interface javax.net.ssl.TrustManager, to get all the certificates for verifying a certificate. Note that the certificate to be used for authentication needs to be accompanied by the corresponding private key whereas certificates for verification have no such requirement.

The SSL library is initialized with default implementations of KeyManager and TrustManager. As we saw earlier, the default KeyManager looks at system properties javax.net.ssl.keyStore, javax.net.ssl.keyStoreType and javax.net.ssl.keyStorePassword to access authentication certificates from an external keystore. If more than one certificate is present in the keystore then one of the certificates matching the signature algorithm of the requested SSL cipher suite, the one found first by the implementation, is used. It is not possible to specify a specific certificate by specifying the alias of the entry in the keystore.

This default behavior is not adequate or appropriate in many real scenarios:

You may not want the keystore password to be stored as a system property, accessible to all code within that JVM. In sensitive applications, the normal practice is to prompt the user for a password, read it within a character array and overwrite the array after use.
You may want to get the certificate and the private key from a source different from a Java keystore. Say you want to access the same certificate used by your Apache or Microsoft IIS WebServer, without duplicating it in a Java KeyStore. This could be an important consideration if the Java program must integrate with an existing PKI infrastructure.
You may want to select the certificate from a list, with input from the user. This is relevant in case of client authentication where the user is prompted to select a certificate from all the available certificates.

The solution is to write your own KeyManager class. The steps involved in writing and using a KeyManager for X.509 certificates are outlined below:

Write a MyKeyManager class that implements interface javax.net.ssl.KeyManager, and supply implementation of all the methods.
Write a provider class for KeyManagerFactory. This class extends java.net.ssl.KeyManagerFactorySpi and returns an array of KeyManager objects, with a single element as the KeyManager written in the previous step.
Register the KeyManagerFactory provider implementation of the previous step with an existing or your own Java Cryptographic Service provider.
For using the newly developed MyKeyManager, get its instance by invoking static method getInstance(), with the appropriate security provider as argument, on class javax.net.ssl.KeyManagerFactory; initialize a javax.net.ssl.SSLContext instance with the KeyManager array returned by the KeyManagerFactory; and get the SocketFactory or ServerSocketFactory from this SSLContext object. Use this factory to create sockets for SSL communication.

We have skipped a lot of details here. You can find them in the JSSE Reference Guide and the Javadoc documentation of various classes.

What about Trust Managers? Analogous to the default Key Manager, the default Trust Manager relies on system properties javax.net.ssl.trustStore, javax.net.ssl.trustStoreType and javax.net.ssl.trustStorePassword to access trusted certificates. The verification mechanism used by the default Trust Manager is simple compared to the PKIX validation we talked about in Chapter 4, PKI with Java and only looks for the presence of the issuer's certificate in the list of trusted certificates. There are situations when you would want to enhance the verification process. For example, a user-facing application may want to present the reason(s) for unsuccessful verification and let the user decide whether or not to continue. Whatever the reason, the mechanism to change the verification process is to write your own MyTrustManager. The steps are similar to those used for a custom MyKeyManager, and are skipped.

< Day Day Up >