0

We are using the JAX-RS 2.0 Client in our WebSphere Liberty Profile application to call an external service. It works fine on WLP 16.0.0.4 with Java 8.0. When I try to run the same application on 17.0.0.4, we are getting certificate errors on the truststore.

After a lot of trial and error, it seems that WLP is no longer loading the truststore from the following property (this is from my jvm.options file): 

-Djavax.net.ssl.trustStore=../../shared/resources/security/trust_yourIBM_TEST.jks

The above worked in 16.0.0.4, but the javax.net.ssl.trustStore property is no longer being used to point to the truststore (if I point the property to a missing file in 16.0.0.4, I get an error that the file is not found, but in 17.0.0.4, I don't get the error). So I added the following:

-Djavax.net.ssl.trustStore=../../shared/resources/security/trust_yourIBM_TEST.jks
-Dcom.ibm.ssl.trustStore=../../shared/resources/security/trust_yourIBM_TEST.jks

This is still not working. I cannot find WLP release notes anywhere that explain that JAX-RS behaves differently in WLP 17.x.

Does anyone know how I can point to the truststore in WLP 17.0.0.4?

==========================================

UPDATE #1 - 2018/01/24

I am using the exact same JDK, server.xml, bootstrap.properties, and jvm.options files, as well as the same application files. The only difference is the WLP instance. I am also using the same entries for the default truststore, which is pointing to the same file as I am pointing to in the jvm.properties I pasted above. Here are the startup log entries: 

17.0.0.4
product = WebSphere Application Server 17.0.0.4 (wlp-1.0.19.201712061531)
wlp.install.dir = C:/IBM/WLP_17.0.0.4/
java.home = C:\IBMJava80\jre
java.version = 1.8.0_151
java.runtime = Java(TM) SE Runtime Environment (8.0.5.7 - pwa6480sr5fp7-20171216_01(SR5 FP7))

16.0.0.4
product = WebSphere Application Server 16.0.0.4 (wlp-1.0.15.cl160420161113-0206)
wlp.install.dir = C:/IBM/WLP_16.0.0.4/
java.home = C:\IBMJava80\jre
java.version = 1.8.0_151
java.runtime = Java(TM) SE Runtime Environment (8.0.5.7 - pwa6480sr5fp7-20171216_01(SR5 FP7))

Here is the error I get in 16.0.0.4 when I change the truststore to a non-existent file: 

[1/24/18 10:50:06:025 EST] 0000006e id=         uribm.services.expensesaggregator.ejb.ExpensesEjbCommonUtils E callUnifiedProfile() Exception has occurred Exception encountered during call to UP: javax.ws.rs.ProcessingException: javax.net.ssl.SSLHandshakeException: SSLHandshakeException invoking https://w3-services1.w3-969.ibm.com/myw3/unified-profile/v1/docs/instances/masterByEmail?email=dlwester%40us.ibm.com: java.security.cert.CertificateException: No X509TrustManager implementation available for [userId=dlwester@us.ibm.com] : javax.net.ssl.SSLHandshakeException: SSLHandshakeException invoking https://w3-services1.w3-969.ibm.com/myw3/unified-profile/v1/docs/instances/masterByEmail?email=dlwester%40us.ibm.com: java.security.cert.CertificateException: No X509TrustManager implementation available

And here are my keystore/truststore entries (the truststore points to the same file as the jvm.options): 

<!-- default keystore -->
<keyStore id="defaultKeyStore"
          location="${keystoreLocation}"
          password="${keystorePassword}" />

<!-- default truststore -->
<keyStore id="defaultTrustStore"
          location="${truststoreLocation}"
          password="${truststorePassword}" />

<ssl id="sslConfig"
     keyStoreRef="defaultKeyStore"
     trustStoreRef="defaultTrustStore"
     sslProtocol="SSL_TLSv2"
     serverKeyAlias="${serverKeyAlias}" />

================

UPDATE #2

I added the transportSecurity-1.0 feature to WLP, and now I am getting an error in 17.0.0.4 if I point to a non-existing file. If I point to the correct truststore file, I am now getting a different error: 

[1/24/18 12:03:19:905 EST] 0000003d id=         com.ibm.w3.security.tai.OAuthDownStreamTAI                   E getSslSocketFactoryWithTrustStore() exception encountered on sslContext.init() for truststore C:/IBM/WLP_17.0.0.4/usr/shared/resources//security/trust_yourIBM_TEST.jks - java.security.KeyManagementException: Default SSLContext is initialized automatically

I need to look into this error.

Westy
  • 707
  • 2
  • 10
  • 23
  • Well Liberty never look at or loaded the javax.net.ssl.* properties. It could be that if you did not have a SSL configuration the server.xml you may have ended up with the JDK's default SSLContext which would get created from the javax.net.ssl.* properties. What exactly is the error you get if the wrong file was provided on 16.0.0.4? There are some changes in SSL starting in 17.0.0.1 around support for outbound SSL. But I really need to figure out what 16.0.0.4 was using in your case, I'm guessing the JDK's default and not a Liberty created SSLContext. – Alaine Jan 24 '18 at 15:11
  • One other question. Was the JDK updated at the same time you updated WLP? What is the level of the JDK you are using? – Alaine Jan 24 '18 at 15:14
  • Alaine, thanks for your reply. Please see UPDATE #1 in my original post above. – Westy Jan 24 '18 at 16:02
  • Also included UPDATE #2 above after adding `transportSecurity-1.0` to the WLP features. – Westy Jan 24 '18 at 18:08
  • The 16.0.0.4 really sounds like an error from the JSSE, wonder if you are using JSSE SSLContext in that case. Is the server.xml file is pointing to an non-existing truststore too? Are you using the ssl-1.0 feature? There is a different in how thing a handled with transportSecurity-1.0 feature. You can find info here https://www.ibm.com/support/knowledgecenter/en/SSAW57_liberty/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/rwlp_liberty_ssl_defaults.html – Alaine Jan 24 '18 at 21:58
  • @Alaine, you steered me in the right direction. I will create an answer explaining what I needed to you, but you deserve the credit! :-) – Westy Jan 25 '18 at 18:54

1 Answers1

0

Alaine steered me in the right direction, so credit for this answer goes to him!

Fortunately, the solution to this problem was not complicated. I had to use the WLP feature transportSecurity-1.0 instead of ssl-1.0.

I had to add the following to my SSL config in server.xml: 

<sslDefault sslRef="sslConfig" />

I also ran into problems with our TAI for OIDC. I had to replace the following statement: 

SSLContext sslContext = SSLContext.getDefault();

with: 

SSLContext sslContext = SSLContext.getInstance("TLSv1.2");

The issue in a nutshell is that the default SSL config is immutable, so you have to make sure you create your own config to override it, not change it.

Westy
  • 707
  • 2
  • 10
  • 23