My environment is a Maven Project and Wildfly (8.2.1) as Application Server. What I need is to connect wihin a incoming REST call to a third party server using SOAP. I need SSL Client Authentication; therefore, I have my own KeyStore and TrustStore. I create therefore my own SSLContext and need to let the WebService use this SSLContext.
There is a problem with Wildfly and it's used implementation of JAXWS (Apache CXF?) - I described it here (but with another aproach to solve the problem; therefore it is not a duplicate post!):
Wildfly: How to use JAXWS-RI instead of Apache CXF (WebService client only)
One of the main problems seems to be that JAXWS used in Wildfly seems to ignore setting the own SSLContext with property com.sun.xml.internal.ws.transport.https.client.SSLSocketFactory
:
MyWS_Service service = new MyWS_Service(null, new QName("http://...", "MyWS"));
MyWS port = service.getMyWSSOAP();
BindingProvider bindingProvider = (BindingProvider) port;
bindingProvider.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "https://hostname:443/.../...");
// the following setting is ignored!
bindingProvider.getRequestContext().put("com.sun.xml.internal.ws.transport.https.client.SSLSocketFactory", mySslSocketFactory);
// in some posts, we see that we need to eliminate 'internal' in the property. This does not help!
bindingProvider.getRequestContext().put("com.sun.xml.ws.transport.https.client.SSLSocketFactory", mySslSocketFactory);
The proof that it is ignored is that if I use HttpsURLConnection.setDefaultSSLSocketFactory(mySslSocketFactory)
to set the SSLContext, it does work - means the SSL connection is established thanks to the imported root CA to the customized TrustStore setup in the SSLContext.
If we look at other posts (e.g. How to programmatically set the SSLContext of a JAX-WS client?) this property should work (even for Wildfly according some comments there). But it does not in my situation. What can be the cause of this?
The problem is definitifely that Apache CXF ignores
bindingProvider.getRequestContext().put(
"com.sun.xml.[internal.]ws.transport.https.client.SSLSocketFactory", mySslSocketFactory);
in oposite to some comments some where.
So my final solution is to programmatically setup the HTTPConduit
used (rather than set a config in a cxf.xml
file).
// Set custom SSLContext.
HTTPConduit conduit = (HTTPConduit) ClientProxy.getClient(port).getConduit();
TLSClientParameters tlsClientParameters = new TLSClientParameters();
tlsClientParameters.setSSLSocketFactory(customSSLContext.getSocketFactory());
conduit.setTlsClientParameters(tlsClientParameters);
I hope that this helps someone having similar issues...