| License Type | SaaS & On-Premise |
| Agent Mode | Assess & Protect |
| Main Product Category | Java Agent |
| Sub Category | Configuration |
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 -javax.net.ssl.trustStoreType=pkcs12 -javax.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.