I am trying to implement a client for a CXF-based web service that I also wrote.
My web service works great (tested working fine via soapUI), but running the client fails with the following:
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(PKIXValidator.java:323) The message clearly points at a certificate problem, so I did a quick search and found the correct approach to supporting SSL in CXF and added the following to my Spring application context config XML:
<http:conduit name="https://myserver/myws/register/soap?wsdl:{http://glob.reg.com/myws}.http-conduit"> <http:tlsClientParameters> <sec:keyManagers keyPassword="password"> <sec:keyStore type="JKS" password="password" file="my/file/dir/Morpit.jks"/> </sec:keyManagers> <sec:trustManagers> <sec:keyStore type="JKS" password="password" file="my/file/dir/Truststore.jks"/> </sec:trustManagers> <sec:cipherSuitesFilter> <!-- these filters ensure that a ciphersuite with export-suitable or null encryption is used, but exclude anonymous Diffie-Hellman key change as this is vulnerable to man-in-the-middle attacks --> <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:authorization> <sec:UserName>Betty</sec:UserName> <sec:Password>password</sec:Password> </http:authorization> <http:client AutoRedirect="true" Connection="Keep-Alive"/> </http:conduit> And rebuilt the client. The client built successfully but I am still getting the same exact error and same exact stack trace, as if I never added this http:conduit thing.
I have not added the certificate to the store yet, and the path to the store is incorrect, but this is intentional as I just wanted to see how the re-built client reports this problem, adjusting to the new http:conduit information.
Instead, I was surprised to see that it was ignored altogether.
What have I missed?
What is the correct way of approaching this?
Update: I just noticed my applicationcontext.xml underlining http:conduit with this error message:
The prefix "http" for element "http:conduit" is not bound. So I did a quick search and found a thread that suggests:
The client needs to configure the HTTP conduit with the keystore that contains the certificate of the STS, e.g.:
<http:conduit name="https://localhost:.*"> <http:tlsClientParameters disableCNCheck="true"> <sec:trustManagers> <sec:keyStore type="jks" password="cspass" resource="clientstore.jks"/> </sec:trustManagers> </http:tlsClientParameters> </http:conduit> Which reinforces what @GreyBeardedGeek wrote. Going to work on this now...