Search

Java Agent does not honor WebSphere configured TrustStore Entries

  • Updated

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

WebSphere maintains its own TrustStore, separate from the TrustStore that is included as part of the Java JRE. The Java Agent starts before WebSphere is fully initialized - so the WebSphere specific TrustStore is not configured. As a result, the Java Agent uses the default TrustStore (located in the Java JRE/lib/security/cacerts file) unless additional configuration is provided to the JVM.

Resolution

Option 1

Install the required certificate(s) into both the JRE cacerts TrustStore in addition to the WebSphere specific TrustStore. This means the certificate chain can be validated by both the Java Agent and your web application.

Option 2

Provide Java with the standard TrustStore system properties to change the TrustStore to be the same as the WebSphere trust store:

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 -Djavax.net.ssl.trustStoreType=pkcs12 -Djavax.net.ssl.trustStorePassword=<your password>

This has the advantage of only requiring the certificate to be installed in one location, i.e. the WebSphere TrustStore.

Note 1: The default password in WebSphere 8.5 and above is WebAS.
Note 2: 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. 

Was this article helpful?

0 out of 0 found this helpful

Have more questions? Submit a request