3 Replies Latest reply on May 9, 2019 5:33 PM by stephan_b

    trustStore/keyStore issue with third party API

    stephan_b
    stephan_b May 1, 2019 1:15 PM

      I have an app that runs on 8.2.1. The app connects to a third party application using their API. Among config attributes, the API needs two KeyStore objects to setup the connection. One for the SSL chain for the server cert, and one for the client certificate that the server requires to authenticate the connection coming from my WildFly instance.

       

      I had to update this API to a newer version to accommodate a major version upgrade of this third party app. The public API methods to setup the connection (using the two KeyStore objects) did not change, but for some reason the connection to the app now fails. It appears that the new API uses a webservice call to setup the connection to the appplication, and now the two KeyStore objects are ignored.

       

      I know this because at first the API was logging "unable to find valid certification path to requested target" which I resolved by defining the javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword system-properties in standalone-full-ha.xml.

      Now the API is able to connect, but still ignores the KeyStore object that contains the client ssl certificate, causing http/401 (not authorized) responses from the application.

       

      If I also define the javax.net.ssl.keyStore and javax.net.ssl.keyStorePassword system-properties, the third party API will initialize and connect successfully once, but every subsequent connection causes an http/401 (not authorized) again.

       

       

      So, what happened here? I see that WildFly kicks off an org.apache.cxf.service.factory.ReflectionServiceFactoryBean class to setup this API connection. I believe that part is new in the new API.

      Why are the KeyStore objects ignored. Is this something WildFly does when using apache CXF? Can I override/configure that behavior?

       

      (note: I cannot update to a later version of WildFly yet. It's an application dependency.)

       

      Edit: I should have added that the new API works fine whenI build a quick command-line Java app for testing. It only misbehaves inside WildFly.

      Edit: Could creating a custom cxf.xml help? I'm still looking into this.