Wildfly's JAXWS implementation seems to ignore bindingProvider property com.sun.xml.ws.transport.https.client.SSLSocketFactory

Question

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?

As described in my comment on your previous post I really think the problem is the `com.sun.xml.internal.ws.transport.https.client.SSLSocketFactory` reference. Did you see this comment? http://stackoverflow.com/a/19587610/152794 — James R. Perkins, May 13 '16 at 15:38
Yes, you are right. It is definitively ignored because Wildfly uses CXF. I also found a solution which I will post next week here.. What I did not understand is that someone posted that it should work in Wildfly with this property set: http://stackoverflow.com/a/23053824/4106030. — badera, May 14 '16 at 18:43

badera · Accepted Answer · 2016-05-18T05:19:36.933

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...

Please, how do you did that? If I try to use the TLSClientParameters class I get the error "java.lang.NoClassDefFoundError: org/apache/cxf/configuration/jsse/TLSClientParameters". I'm using the jbossws-cxf-client artifact on my POM . — lucasdclopes, Apr 04 '20 at 09:14

score 6 · Answer 2 · answered Jun 21 '19 at 20:47

6

Apache CXF ignores the JAX-WS properties. You can specify the TLS Client Parameters programmatically the following way:

TLSClientParameters tlsParams = new TLSClientParameters();
tlsParams.setUseHttpsURLConnectionDefaultSslSocketFactory(false);
tlsParams.setSSLSocketFactory(sslSocketFactory);
bindingProvider.getRequestContext().put(TLSClientParameters.class.getName(), tlsParams);

answered Jun 21 '19 at 20:47

Vladimir Nemergut

61
1
3

1

Vladimir it works ! I wonder where did you find it. – Sameer Sarmah Jun 27 '22 at 16:08
I am usin Wildfly 22 and it's throwing exception in runtime: ClassNotFound for TLSClientParameters. Any solution? – carpics Oct 25 '22 at 20:49

score 4 · Answer 3 · edited Nov 07 '17 at 16:43

When using the HTTPConduit solution for Wildfly 10 I had to add jboss-deployment-structure.xml

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
    <deployment>
        <dependencies>
  <module name="org.jboss.ws.cxf.jbossws-cxf-client" services="import" />

  <module name="org.apache.cxf.impl" export="true">  
       <imports>  
            <include path="META-INF" />  
            <include path="META-INF/cxf" />  
            <include path="META-INF/services" />  
       </imports>         
  </module>   
        </dependencies>
    </deployment>

</jboss-deployment-structure>

score 1 · Answer 4 · answered Oct 23 '17 at 16:32

My solution to Widfly 8.2.1:

1) Add the file src/main/resources/META-INF/services/javax.xml.ws.spi.Provider with the line com.sun.xml.ws.spi.ProviderImpl inside

2) Add the maven dependency:

<dependency>
     <groupId>com.sun.xml.ws</groupId>
     <artifactId>jaxws-rt</artifactId>
     <version>2.2.8</version>
</dependency>

3) Add the SSLSocketFactory this way:

bindingProvider.getRequestContext().put("com.sun.xml.ws.transport.https.client.SSLSocketFactory", mySslSocketFactory);

Wildfly's JAXWS implementation seems to ignore bindingProvider property com.sun.xml.ws.transport.https.client.SSLSocketFactory

4 Answers4

Linked