3.30.2011

This case
study describes the complete steps from root cause analysis to resolution of an
SSL communication problem between a Weblogic 11g client application and remote
Web Service provider that we faced recently when migrating our application from
Weblogic 8.1 to Weblogic 11g.

It will also demonstrate the importance for proper understanding
of the SSL and Java keystore principles as this is a common problem you may
face with a Java EE environment using SSL to communication with your service
providers / downstream systems.

Our application backend calls to a remote Web Service
provider were unable to complete proper SSL handshake due the above error. The
problem was that the certificate of the downstream server was not trusted by
the Weblogic 11g / JSSE provider.

Error detail

The error detail below did reveal an IBM JSSE2 component
as the source of the SSL handshake failure: com.ibm.security.cert.CertPathUtil.findIssuer(CertPathUtil.java:298) and did reveal the
following fact:

·Fact #1: The failure is
triggered during the SSL issuer verification check between the client (Weblogic
11g) list of trust Root
CA’s and the remote
server SSL certificate issuer found at the root of the certificate path

The SSL and Java keystore configuration was verified in the Weblogic 11g
console which did not reveal any problem. By default, Weblogic is using DemoTrust and JRE trust (cacerts); which contain the ROOT CA
signature for most SSL trusted provider such as Entrust which we use in our
enterprise.

The remote server issuer was also verified against our Weblogic 11g JRE 1.6 trust keystore (cacerts) which did not reveal any problem and a perfect match.

Java trust keystore runtime verification

Given no clear indication on the root cause at this point, we decided to
add additional tracing and verified the location of the trust keystore at
runtime. The following code was executed from a test JSP page in order to
verify each value at runtime:

//The loaded JSSE trust keystore location

System.getProperty("javax.net.ssl.trustStore"); // mismatch found!

//The Java Home of your Java VM running Weblogic 11g

System.getProperty("java.home");

//The loaded JSSE trust keystore type

System.getProperty("javax.net.ssl.trustStoreType");

//The JSSE trust keystore provider & encrypted password

System.getProperty("javax.net.ssl.trustStoreProvider");

System.getProperty("javax.net.ssl.trustStorePassword");

·Fact #2: The additional
tracing did reveal a mismatch of the location of the trust keystore since it
was pointing to an application specific keystore containing only some custom
self-signed CA’s and no Entrust ROOT CA

Root cause and resolution

Additional analysis of the application did reveal an
override of the trust keystore location (javax.net.ssl.trustStore) which was leading
to a SSL communication failure with our remote service provider since all
Entrust ROOT CA’s were missing at runtime.

The application was updated and reconfigured in order to
use the default JSSE trust keystore and ensure no override of the global Javax
JSSE / SSL System properties.

·Please
enable SSL debug in order to analyse the SSL handshake process and understand
the source of the failure. These traces are really helpful and will help you
pinpoint the root cause

·Please consider adding code to print the
runtime value of the Javax SSL specific System properties. This can really help
you pinpoint any wrong SSL configuration or override of your expected SSL /
JSSE configuration parameters