Hi Glen,
Thanks again! Putting the self-signed cert in cacerts worked (sort of). At least the validation of the cert worked. The call eventually failed however, since the username/password (specified in the cxf.xml file) were not transmitted and the call failed due to lack of credentials.
So, the problem appears to be that my runtime is not loading the cxf.xml settings. The app is a spring-based application.
I've tried loading the settings in two ways. Both apparently fail to load the username/password credentials (and presumably all of the other cxf settings):
1. cxf.xml located in WEB-INF/classes (my understanding is that cxf will automatically look for the cxf.xml file here)
2. putting the cxf config settings inside my apps main spring config file (inside the <beans></beans> block).
Any ideas would be most appreciated! :)
Thanks,
Mark
Thanks again! Putting the self-signed cert in cacerts worked (sort of). At least the validation of the cert worked. The call eventually failed however, since the username/password (specified in the cxf.xml file) were not transmitted and the call failed due to lack of credentials.
So, the problem appears to be that my runtime is not loading the cxf.xml settings. The app is a spring-based application.
I've tried loading the settings in two ways. Both apparently fail to load the username/password credentials (and presumably all of the other cxf settings):
1. cxf.xml located in WEB-INF/classes (my understanding is that cxf will automatically look for the cxf.xml file here)
2. putting the cxf config settings inside my apps main spring config file (inside the <beans></beans> block).
Any ideas would be most appreciated! :)
Thanks,
Mark
On Apr 17, 2012, at 06:14 PM, Glen Mazza <[email protected]> wrote:
My guess is that your SOAP client is not detecting the truststore that
you've configured for it (configuration syntax problem somewhere), and
is instead looking for the server's public key in the JRE's truststore
(the cacerts file) instead, and not finding it. (See Step #8 of my SSL
tutorial you've referenced.) That error message you're getting is most
commonly because of that. You can probably confirm that's the issue by
placing the server cert in the cacerts file and it would probably run
without error.
The name attribute to your http:conduit element might be the
configuration problem -- I'd temporarily switch it to "*.http-conduit"
without the namespace (that should activate that element for every SSL
call), then change it again to the precise port name w/the namespace
(don't use an asterisk this time).
HTH,
Glen
On 04/17/2012 05:44 PM, Mark Thompson wrote:
> Hi All,
>
> I've hit a wall and need to reach out for advice and clarity from this
> group! :)
>
> *
> Problem*:
> I keep getting a ClientTransportException:
>
> "/com.sun.xml.ws.client.ClientTransportException: HTTP transport
> error: javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to
> find valid certification path to requested target/"
>
> I have configured my channel and settings according to the cxf
> documentation and the many posts I've read by users of this group,
> most notably Glen Mazza's post
> (http://www.jroller.com/gmazza/entry/ssl_for_web_services).
>
>
>
> *Summary*:
> 1. I'm writing the soap client code using 2-way auth. (server
> self-signed certificate, username/password from me, and over ssl).
> I'm using cxf 2.5.2
>
> 2. I do not have control over the server-side. However, I have
> verified that the server "works" by hitting the soap service using
> SoapUI (with auth enabled).
>
> 3. It appears the problem is in the way I'm configuring SSL in my
> client code.
>
> 4. my conduit block (in cxf.xml) looks like this:
>
> <http:conduit name="{http://foo.bar.com/service}*.http-conduit">
> <http:authorization>
> <sec:UserName>myUserName</sec:UserName>
> <sec:Password>myPassword</sec:Password>
> </http:authorization>
>
> <http:tlsClientParameters disableCNCheck="true"
> secureSocketProtocol="SSL">
> <sec:trustManagers>
> <sec:keyStore type="JKS" password="password"
> file="/Users/myaccount/Downloads/CertStuff/trustcert.jks"/>
> </sec:trustManagers>
>
> <sec:keyManagers>
> <sec:keyStore type="JKS" password="password"
> file="/Users/myaccount/Downloads/CertStuff/keystore.jks"/>
> </sec:keyManagers>
>
> <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_NULL_.*</sec:include>
> <sec:exclude>.*_DH_anon_.*</sec:exclude>
> </sec:cipherSuitesFilter>
> </http:tlsClientParameters>
> </http:conduit>
>
> 5. The above is the only SSL/CXF config I do. The cxf.xml file is
> properly located in WEB-INF/classes in tomcat.
>
> 6. I made the trustcert.jks and keystore.jks files using keytool and
> the server self-signed certificate .cer file.
>
> 7. Programmatically, I verify the target url is the expected
> "https://...." service end point (from Glen Mazza's blog).
>
> BindingProvider portBP = (BindingProvider) servicePort;
> String urlUsed = (String)
> portBP.getRequestContext().get(BindingProvider.ENDPOINT_ADDRESS_PROPERTY);
> System.out.println("Using URL: " + urlUsed);
>
>
> 8. Programmatically, I find that the context does NOT contain the
> expected username/password from the cxf.xml config file.
>
> String username = (String)
> portBP.getRequestContext().get(BindingProvider.USERNAME_PROPERTY);
> String password = (String)
> portBP.getRequestContext().get(BindingProvider.PASSWORD_PROPERTY);
>
> (both username and password are null in the above 2
> lines of code).
>
> 9. Is there anyway I can verify the cxf.xml file is actually processed
> and the http:conduit conf settings are processed?
>
> 10. I would appreciate any and all suggestions as to why I'm getting
> the ClientTransportException.
>
>
> Thanks in advance!
> Mark
>
>
>
>
> **
--
Glen Mazza
Talend Community Coders
coders.talend.com
blog: www.jroller.com/gmazza
