WEB-INF/classes (if that would work), would just be for applications
hosted as a WAR in a servlet container (and normally would just go under
WEB-INF directly). Is your web service client (as opposed to the web
service provider) being hosted on Tomcat?
If no, when you run a standalone client, normally you'll place the
cxf.xml files under src/main/resources, and Maven will place it properly
in the classpath for you when the app is run via mvn exec:java or
exec:exec. I would first try to get your web service client to run
standalone before trying to run it as a WAR (if that's your goal.)
Glen
On 04/18/2012 02:38 PM, Mark Thompson wrote:
> 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
>
>
>
>
>
> On Apr 17, 2012, at 06:14 PM, Glen Mazza <[email protected]
<mailto:[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 <http://javax.net>
<http://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://foo.bar.com/service%7D*.http-conduit>
>> <http://foo.bar.com/service%7D*.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 <http://www.jroller.com/gmazza>
<http://www.jroller.com/gmazza>
>>
--
Glen Mazza
Talend Community Coders - coders.talend.com
blog: www.jroller.com/gmazza <http://www.jroller.com/gmazza>
