Java Agent does not honor WebSphere configured TrustStore Entries

Issue

As detailed in the article Java Agent Fails to Connect to Contrast UI: javax.net.ssl.SSLHandshakeException, one of the options for resolving a certificate trust issue is to import a certificate into the TrustStore used by the application server hosting the application that the Java Agent is instrumenting.

In the case of IBM's WebSphere Application Server (WAS), the normal process of importing the certificate via the WAS console does not resolve the trust issue.

Cause

Due to the timing involved in WAS and the JVM (and therefore the Contrast Java Agent) starting up, the WAS configured TrustStores are not available to the Java Agent when it first tries to connect to the Contrast UI. 

Resolution

Java allows for the TrustStore (and associated password and type) to be overridden via the JVM System Properties:

javax.net.ssl.trustStore
javax.net.ssl.trustStoreType
javax.net.ssl.trustStorePassword

Because these are specified at JVM startup, they will be honored by the JVM and therefore the Java Agent.  An example configuration would look something like this:

-Djavax.net.ssl.trustStore=/apps/ki01/xa-was90-dv114/AppServer/profiles/xa-dmgr90-dv114/config/cells/xa-cell90-dv114/trust.p12 -javax.net.ssl.trustStoreType=pkcs12 -javax.net.ssl.trustStorePassword=<your password>

Note: As documented in this IBM help article, WAS allows for the option of xor encoding passwords such as the TrustStore password referenced above, however this is a WAS specific feature and is not natively honored by the JRE, and as such will not work with the Contrast Agent which relies on the JVM for connectivity.  The effectiveness of xor encoding as a security measure is questionable as there are several online resources that can be used to decode such passwords, but for the Java Agent to successfully access resources that rely on the accessibility of certificates stored in such TrustStores, the password must be specified un-encoded.