You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Mark Thompson <ma...@me.com> on 2012/04/17 23:44:48 UTC
configure SOAP client for SSL questions.
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
Re: configure SOAP client for SSL questions.
Posted by Mark Thompson <ma...@me.com>.
Hi Glen,
Thanks! I'll try that and report my findings back to the list.
One question though: I'm still baffled why the username/password were null when I tried to access them programmatically. It makes me wonder if the cxf.xml file is even being processed. Any ideas?
Thanks again!
Mark
On Apr 17, 2012, at 6:14 PM, Glen Mazza 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
>
Re: configure SOAP client for SSL questions.
Posted by Glen Mazza <gm...@talend.com>.
Did you add the cxf.xml file to your contextConfigLocation in the
web.xml (http://www.jroller.com/gmazza/entry/web_service_tutorial#WFstep5)?
Glen
On 04/19/2012 05:00 PM, Mark Thompson wrote:
> Hi Glen,
>
> Results of test show that my cxf..xml settings are not being consumed
> on startup. I also tried putting them in the app's main spring config
> xml file with the same result.
>
> Based on your advice, I created a small stand-alone test client app
> that hits the service. cxf.xml in src/main/resources. This works fine.
>
> Very odd that my cxf config info is not being consumed in our main
> webapp. The spring config file looks like any standard config file,
> but with the additions to the namespace and schemaLocation sections at
> the top to account for the addition of a soap client.
>
> Cheers,
> Mark
>
>
>
>
> On Apr 18, 2012, at 12:01 PM, Glen Mazza <gm...@talend.com> wrote:
>
>> 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 <gmazza@talend.com
>> <ma...@talend.com>> 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>
>>
--
Glen Mazza
Talend Community Coders - coders.talend.com
blog: www.jroller.com/gmazza
Re: configure SOAP client for SSL questions.
Posted by Mark Thompson <ma...@me.com>.
Hi Glen,
Results of test show that my cxf..xml settings are not being consumed on startup. I also tried putting them in the app's main spring config xml file with the same result.
Based on your advice, I created a small stand-alone test client app that hits the service. cxf.xml in src/main/resources. This works fine.
Very odd that my cxf config info is not being consumed in our main webapp. The spring config file looks like any standard config file, but with the additions to the namespace and schemaLocation sections at the top to account for the addition of a soap client.
Cheers,
Mark
On Apr 18, 2012, at 12:01 PM, Glen Mazza <gm...@talend.com> wrote:
> 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 <gm...@talend.com> 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>.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: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>
> >>
>
>
> --
> Glen Mazza
> Talend Community Coders - coders.talend.com
> blog: www.jroller.com/gmazza
>
Re: configure SOAP client for SSL questions.
Posted by Glen Mazza <gm...@talend.com>.
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 <gm...@talend.com> 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>.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: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>
>>
--
Glen Mazza
Talend Community Coders - coders.talend.com
blog: www.jroller.com/gmazza
Re: configure SOAP client for SSL questions.
Posted by Mark Thompson <ma...@me.com>.
One more detail:
My pom.xml has this for cxf dependency:
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-jaxws</artifactId>
<version>${cxf.version}</version>
</dependency>
where cxf.version is 2.5.2
Don't know if that is affecting anything; I believe I've got the pom.xml parts correct since the app builds and runs (except for the security parts) (i.e. I can run the client against a local mock Soap service using the same wsdl, but without needing credentials).
Mark
On Apr 18, 2012, at 11:38 AM, Mark Thompson <ma...@me.com> 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 <gm...@talend.com> 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
>>
Re: configure SOAP client for SSL questions.
Posted by Mark Thompson <ma...@me.com>.
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 <gm...@talend.com> 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
>
Re: configure SOAP client for SSL questions.
Posted by Glen Mazza <gm...@talend.com>.
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