Weblogic kills CXF's SSL configuration?

Question

Good time!

I've created a simple CXF client to communicate with a remote service protected by SSL. If I run a JUnit test a handshake performs without mistakes and the communication goes normally.

<http:conduit name="<service_namespace_port>.http-conduit">
   <http:client AutoRedirect="true" Connection="Keep-Alive"/>
   <http:tlsClientParameters secureSocketProtocol="SSL" disableCNCheck="true">
    <sec:keyManagers keyPassword="pass">
        <sec:keyStore type="JKS" password="pass" file="keystore"/>
    </sec:keyManagers>
    <sec:trustManagers>
        <sec:keyStore type="JKS" password="pass" file="truststore"/>
    </sec:trustManagers>
    <sec:cipherSuitesFilter>
        <sec:include>.*_EXPORT_.*</sec:include>
        <sec:include>.*_EXPORT1024_.*</sec:include>
        <sec:include>.*_WITH_DES_.*</sec:include>
        <sec:include>.*_WITH_AES_.*</sec:include>
        <sec:include>.*_WITH_NULL_.*</sec:include>
        <sec:exclude>.*_DH_anon_.*</sec:exclude>
    </sec:cipherSuitesFilter>
</http:tlsClientParameters>

If I deploy my application on a Weblogic Server (11g) and perform a request, the handshake fails with the error "unable to find valid certification path to requested target". According to the logs got by the "-Djavax.net.debug=all", the problem is Weblogic gets its java cacert (/jre/lib/security) ignoring the configured CXF client's truststore.

I've tried to write a line <package-name>javax.jws.*</package-name> in the weblogic-application.xml, but this kills the application with the error "org.springframework.beans.MethodInvocationException: Property 'serviceClass' threw exception; nested exception is java.lang.NoClassDefFoundError: javax/jws/WebService".

Can somebody, please, suggest, how to tell weblogic not to participate in the clent-server communication?

EDIT. This is the full client configuration (Spring-CXF):

<http:conduit name="<service_namespace_port>.http-conduit">
        <http:client AutoRedirect="true" Connection="Keep-Alive"/>
        <http:tlsClientParameters secureSocketProtocol="SSL" disableCNCheck="true">
            <sec:keyManagers keyPassword="pass">
                <sec:keyStore type="JKS" password="pass" file="keystore"/>
            </sec:keyManagers>
            <sec:trustManagers>
                <sec:keyStore type="JKS" password="pass" file="truststore"/>
            </sec:trustManagers>
            <sec:cipherSuitesFilter>
                <sec:include>.*_EXPORT_.*</sec:include>
                <sec:include>.*_EXPORT1024_.*</sec:include>
                <sec:include>.*_WITH_DES_.*</sec:include>
                <sec:include>.*_WITH_AES_.*</sec:include>
                <sec:include>.*_WITH_NULL_.*</sec:include>
                <sec:exclude>.*_DH_anon_.*</sec:exclude>
            </sec:cipherSuitesFilter>
        </http:tlsClientParameters>
    </http:conduit>

    <jaxws:client id="service"
                  serviceClass="foo.bar.ServiceClass"
                  address="<service_url>" />
    <bean id="client" class="foo.bar.ClientClass"/>

EDIT. Accordng to this post, I've changed the <http:conduit name="<service_namespace_port>.http-conduit"> to <http:conduit name="*.http-conduit"> and now I'm getting the error "nested exception is java.lang.RuntimeException: Cannot create a secure XMLInputFactory". Some time ago I had this error and the solution I've found is using the system property. But it does not fit any more... Does anybody know, how to fix this?

Have you checked the specific server configuration for weblogic at Apache CXF website ? http://cxf.apache.org/docs/application-server-specific-configuration-guide.html — Cristian Meneses, Jul 09 '13 at 14:43
Yes, and as I wrote in the question, this configuration kills the deployment. Please, see a paragraph with the "javax.jws.*" line. Do you know, how to fix this? — Dmitry, Jul 09 '13 at 14:48
Since your are telling Weblogic to prefer `javax.jws.*`packages in your EAR/WAR, do you have JAX-WS libs packaged in your application ? — Cristian Meneses, Jul 09 '13 at 14:51
It seems that there is no such libs, as far as it fails. But if there is no such libs, CXF does not use them. If it does, it would contain them as dependencies and Maven would download them for it and the deployment won't fail. Please, correct me if I'm mistaken. — Dmitry, Jul 09 '13 at 14:59
I've posted an answer on my findings, please let me know how it goes, so I can help you if you need something else. — Cristian Meneses, Jul 09 '13 at 15:04
Thank you very much, I'll try it in 5 minutes. Could you, please, explain why these dependencies are required (cause if I don't use SSL, there is np problem to connect to a remote service). I'm using CXF 2.7.5 — Dmitry, Jul 09 '13 at 15:09
Because almost all application servers include their own webservice stack, with custom implementations on secutiry concerns and other things. Since you are working with a provided framework (CXF), depending on classloader behavior, it will try to provide the missing dependencies (if any) from the appserver libs, which can lead to this kind of errors. Usually no-ssl services will not present problems. — Cristian Meneses, Jul 09 '13 at 15:11

score 3 · Accepted Answer · edited May 23 '17 at 12:23

Finally, I've a solution for both problems.

First of all, I'd like to thank Cristian Meneses for really helpful answers!

Next, please, see my answer in this post for the "Cannot create a secure XMLInputFactory" issue solution. And after that, check this post for the http:conduit name configuration (in my case I've used such construction: <http:conduit name="*.http-conduit">). Mixin this information I've managed to make my application work.

So, as far as I understand, the main idea is when WLS matches the conduit's name it uses the configured CXF's client keystores, but if it doesn't, it uses the cacerts.

HINT FOR WONDERS: it is not really necessary (but strongly recommended) to name the http:conduit bean as it said in the official documentation (my aim was to make the service endpoint configurable). The http:conduit bean's name is a template for matching a service name you want to connect to. Please, referer to the ticket. There is a great workaround, provided by Jason Pell.

Cristian Meneses · Answer 2 · 2013-07-09T15:57:45.347

0

You seem to be missing a dependency.. geronimo-ws-metadata_2.0* (don't know which specific version for your CXF version).

Also on Maven Central, this dependency seems to apply only to cxf-buldle, maybe that's why Maven didn't include it for you...

By the way, this applies if you keep using <package-name>javax.jws.*</package-name>, since geronimo-ws-metadata_2.0* contains the missing interface

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

This is my config to get the conduit working

<!-- OVERRIDE DEFAULT TRUSTSTORE, USE BUNDLE TRUSTSTORE INSTEAD -->
<http:conduit name="{http://myWebserviceNamespace/}myWebservicePort.http-conduit">
    <http:tlsClientParameters>
        <sec:trustManagers>
            <sec:keyStore type="JKS" password="myPass"
                 resource="myTrustStore.jks" />
             </sec:trustManagers>
     </http:tlsClientParameters>
</http:conduit>     

<jaxws:client id="myClient"
       serviceClass="com.example.webservice.MyService"
       address="https://path.to/MYSERVICE/services/MyWebservice"/>

I had to use "resource" instead of "file", since my truststore was on the classpath

edited Jul 09 '13 at 15:57

answered Jul 09 '13 at 15:04

Cristian Meneses

4,013
17
32

Sorry, the deployment process took time. This solution fixed the spring configuration ("javax.jws.*" problem), but didn't solve the main trouble. Weblogic as previously uses the jdk1.6.0_45\jre\lib\security\cacerts. – Dmitry Jul 09 '13 at 15:27
Can you please post the spring context where your webservice client is defined ? I struggled with this on a Websphere App Server some days ago, maybe I can help you with this.. With "main problem" you mean it keeps using the `jre/lib/sercurity/cacerts` truststore ? – Cristian Meneses Jul 09 '13 at 15:30
Sure. Please, see the edit. The main problem is Weblogic kills the CXF's configuration – Dmitry Jul 09 '13 at 15:36
The last solution I see is to set my truststore to Weblogic, but it seems a bad idea cause after that I don't see reasons to configure CXF – Dmitry Jul 09 '13 at 15:38
1

I've added my example config to answer... Maybe it can help – Cristian Meneses Jul 09 '13 at 15:55

Weblogic kills CXF's SSL configuration?

2 Answers2