Hi, Using the cxf client stuff definately works as I have just finished a fairly substantial piece of work in this area to support both ssl and mutual ssl.
First off I would suggest simplify your conduit match to be: <http:conduit name="*.http-conduit"> You can change it back later, but this will ensure a typo is not preventing your http client config being applied. Second change the file references to be Absolute initially, as you have it working via system properties with absolute file reference. Once you have a working cxf:client, then you can start backing out some of your changes to get back to a relative reference. Get rid of the Keystore block from your client xml as its only required for Mutual SSL and may actually be part of your problems. If you want to create your own keystore / truststore combo - I have a linux script that makes short work of it :-) too https://github.com/pellcorp/cxf/blob/master/JavaFirst/keytool.sh Let me know how Cheers Jason On Tue, Mar 19, 2013 at 3:08 AM, Florin Pop <[email protected]> wrote: > Thank you very much Lukasz! :D You had > right!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > I added the next two lines to my code in order to pass the server's > certificate to the client's runtime and it WORKS! > System.setProperty("javax.net.ssl.trustStore","D:/workspace/zzSSLTestClient/src/main/java/clientKeystore.jks"); > System.setProperty("javax.net.ssl.trustStorePassword","cspass"); > > > On Mon, Mar 18, 2013 at 5:11 PM, Lukasz Salwinski <[email protected]>wrote: > >> On 03/18/2013 07:49 AM, Florin Pop wrote: >> >>> Hello everybody! >>> >>> *I tried to create a WS-Client that uses a secure SSL connection with CXF >>> >>> framework. Thus, I created a spring configuration file following the model >>> >> >> [...] >> >> *When i run the code, the following error occures: >>> >>> >>> Caused by: sun.security.validator.**ValidatorException: PKIX path >>> building >>> failed: sun.security.provider.**certpath.**SunCertPathBuilderException: >>> unable >>> to find valid certification path to requested target >>> at sun.security.validator.**PKIXValidator.doBuild(Unknown Source) >>> at sun.security.validator.**PKIXValidator.engineValidate(**Unknown >>> Source) >>> at sun.security.validator.**Validator.validate(Unknown Source) >>> at sun.security.ssl.**X509TrustManagerImpl.validate(**Unknown >>> Source) >>> at sun.security.ssl.**X509TrustManagerImpl.**checkTrusted(Unknown >>> Source) >>> at sun.security.ssl.**X509TrustManagerImpl.** >>> checkServerTrusted(Unknown >>> Source) >>> ... 30 more >>> Caused by: sun.security.provider.**certpath.** >>> SunCertPathBuilderException: >>> unable to find valid certification path to requested target >>> at >>> sun.security.provider.**certpath.SunCertPathBuilder.**engineBuild(Unknown >>> Source) >>> at java.security.cert.**CertPathBuilder.build(Unknown Source) >>> >> >> [...] >> >> Hello, >> it looks like either client or server (or both) does not have access to >> the >> security certificatete - in order to get Jave SSL server/client pair talk >> to >> each other they both must have access to the same (server's public) >> security >> certificate. The somewhat complicated procedure to self-generate one and >> use >> when communicating over SSL is described, for example here: >> >> http://docs.oracle.com/javase/**6/docs/technotes/guides/** >> security/jsse/JSSERefGuide.**html#CreateKeystore<http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#CreateKeystore> >> >> It boils down to: >> * self-generating a file (say, keystore) with certificate for the server >> >> * passing it to the server's java runtime: >> java -Djavax.net.ssl.keyStore=**keystore .... >> >> * importing the same certificate into a file (say, truststore) containing >> info about trusted servers known to a client >> >> * passing it to the clients's java runtime: >> java -Djavax.net.ssl.trustStore=**truststore .... >> >> hope it helps >> lukasz >> >> >> -- >> ------------------------------**------------------------------** >> ------------- >> Lukasz Salwinski PHONE: 310-825-1402 >> UCLA-DOE Institute for Genomics & Proteomics FAX: 310-206-3914 >> UCLA, Los Angeles EMAIL: [email protected] >> ------------------------------**------------------------------** >> ------------- >>
