You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Jim Schneider <js...@revolutionehr.com> on 2010/02/11 18:25:05 UTC

CXF client SSL pain

CXF 2.2.4 client trying to access an Axis2 soap web service over SSL

I can't get my CXF client to get past the SSL handshake, but the sample
Axis2 client from the web service developer works fine. Here's my config:

   <http:conduit name="*.http-conduit">
	
	    <http:tlsClientParameters secureSocketProtocol="SSL"
disableCNCheck="true">				
	      <sec:keyManagers >		  
	            <sec:keyStore type="PKCS12" password="testing" 										
file="C:\projects\hit-ws\Epp\test.eyeappts.com.p12"
		    />								
	      </sec:keyManagers>		  
	      <sec:trustManagers>		  
				<sec:keyStore type="JKS" password="trustword" 
					file="C:\projects\hit-ws\Epp\truststore"
				/>														
	      </sec:trustManagers>		  		  
	      <sec:cipherSuitesFilter>
			  <sec:include>.*{_}WITH_3DES{_}{*}*.*</sec:include>
			  <sec:include>.*{_}EXPORT{_}{*}*.*</sec:include>
			  <sec:include>.*{_}EXPORT1024{_}{*}*.*</sec:include>
			  <sec:include>.*{_}WITH_DES{_}{*}*.*</sec:include>
			  <sec:include>SSL_RSA_WITH_RC4_128_MD5</sec:include>
			  <sec:include>SSL_RSA_WITH_RC4_128_SHA</sec:include>
			  <sec:exclude>.*{_}WITH_NULL{_}{*}*.*</sec:exclude>
			  <sec:exclude>.*{_}DH_anon{_}{*}*.*</sec:exclude>
	      </sec:cipherSuitesFilter>		  
	    </http:tlsClientParameters>		
   </http:conduit>

I'm logging/tracing the SSL for both the successful Axis2 client and
unsuccessful CXF client and I see the ServerHelloDone message on both. Then,
on the Axis2 client, I see a "Certificate chain" message with a single entry
right before the ClientKeyExchange. On the CXF client, I see the
"Certificate chain" header, but no entry. 

Then, for the ClientKeyExchange, the Axis2 client sends 2 - 926 byte
messages, whereas the CXF client sends 2 - 141 byte messages. The Axis2
client finishes the SSL handshake successfully and moves on to the
application data. The CXF client has a failed handshake and then restarts
the ClientHello phase again. 

I'm stuck. Any help is appreciated. I can send complete SSL outputs for both
if that would help.
-- 
View this message in context: http://old.nabble.com/CXF-client-SSL-pain-tp27551100p27551100.html
Sent from the cxf-user mailing list archive at Nabble.com.


Re: CXF client SSL pain

Posted by Jim Schneider <js...@revolutionehr.com>.
Well, I have researched this one now and am stuck again. I'm confused about
the following:

1. The "real" WSDL is secured behind SSL. Given the SSL issues before, I'm
unable to generate the client stubs using the remote URL. So, I've stored
the WSDL to a local file and referenced that to generate the client code.
Now, at runtime, I don't know whether I should (or need to) access the
"real" WSDL URL, or again reference the local file WSDL. Does it matter? Is
it ok if the WSDL is behind SSL?

2. In either case, it seems as if it's pulling the endpoint URL from the
WSDL port.address.location attribute. This may or may not be set
appropriately by the web service developer, but it doesn't seem like it
should matter if I know what the URL is. Can't I override what is specified
by the WSDL? As an example, I've exposed my own web services with CXF and
the WSDL that is generated has "http://locahost...blah". Obviously,
localhost is not appropriate for anyone else consuming my web services. But
an axis2 client is successfully accessing my services since axis2 doesn't
seem to rely on the WSDL to get the "real" endpoint URL.

I'm sure I'm missing something basic here. Or maybe this is just how the CXF
client works and is different than some of the other ws client tools.

Thanks for any suggestions.

Jim




Jim Schneider wrote:
> 
> I now, however, have a different error:
> 
>      [java] Payload: 
>      [java] --------------------------------------
>      [java] Feb 11, 2010 2:28:24 PM
> org.apache.cxf.phase.PhaseInterceptorChain doIntercept
>      [java] WARNING: Interceptor has thrown exception, unwinding now
>      [java] org.apache.cxf.binding.soap.SoapFault: Error reading
> XMLStreamReader.
>      [java] 	at
> org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:196)
>      [java] 	at
> org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:58)
>      [java] 	at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
> ....
>      [java] Caused by: com.ctc.wstx.exc.WstxEOFException: Unexpected EOF
> in prolog
>      [java]  at [row,col {unknown-source}]: [1,0]
>      [java] 	at
> com.ctc.wstx.sr.StreamScanner.throwUnexpectedEOF(StreamScanner.java:686)
>      [java] 	at
> com.ctc.wstx.sr.BasicStreamReader.handleEOF(BasicStreamReader.java:2134)
>      [java] 	at
> com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:2040)
>      [java] 	at
> com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1069)
>      [java] 	at
> com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1095)
>      [java] 	at
> org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:93)
> 
> but I haven't researched this one yet.
> 
> 

-- 
View this message in context: http://old.nabble.com/CXF-client-SSL-pain-tp27551100p27558792.html
Sent from the cxf-user mailing list archive at Nabble.com.


Re: CXF client SSL pain

Posted by Jim Schneider <js...@revolutionehr.com>.
cipherSuites are ok.

I made the suggested changes (cleaned up the cipher filter and put the
key/trust stores in the current directory. No love. 

Interestingly, after my original post, I found another post that had success
essentially commenting out everything but the main tlsClientParameters
element. I did the same thing, then added this to my Java client code:

		System.setProperty("javax.net.ssl.keyStoreType","PKCS12");
		System.setProperty("javax.net.ssl.keyStore","test.eyeappts.com.p12");
		System.setProperty("javax.net.ssl.keyStorePassword","testing");			
		System.setProperty("javax.net.ssl.trustStore","truststore");
		System.setProperty("javax.net.ssl.trustStorePassword","trustword");		

And now I get past the SSL handshake and into application data. 

I now, however, have a different error:

     [java] Payload: 
     [java] --------------------------------------
     [java] Feb 11, 2010 2:28:24 PM
org.apache.cxf.phase.PhaseInterceptorChain doIntercept
     [java] WARNING: Interceptor has thrown exception, unwinding now
     [java] org.apache.cxf.binding.soap.SoapFault: Error reading
XMLStreamReader.
     [java] 	at
org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:196)
     [java] 	at
org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:58)
     [java] 	at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
....
     [java] Caused by: com.ctc.wstx.exc.WstxEOFException: Unexpected EOF in
prolog
     [java]  at [row,col {unknown-source}]: [1,0]
     [java] 	at
com.ctc.wstx.sr.StreamScanner.throwUnexpectedEOF(StreamScanner.java:686)
     [java] 	at
com.ctc.wstx.sr.BasicStreamReader.handleEOF(BasicStreamReader.java:2134)
     [java] 	at
com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:2040)
     [java] 	at
com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1069)
     [java] 	at
com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1095)
     [java] 	at
org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:93)

but I haven't researched this one yet.






dkulp wrote:
> 
> 
> 
> I'm not really sure what's happening.   Can you check the Client Hello
> token 
> sent and make sure the cipher suites that are being sent to the server are
> OK?  
> You cipherSuitesFilter thing looks a bit strange, but it just may be the
> mail 
> client doing something.   Normally, they would look like:
> 
> <sec:include>.*_EXPORT_.*</sec:include>
> 
> without all the { and } thing in there.    That said, I would have still 
> expected  a key to be sent of some sort so I'm not sure if the keyManager 
> thing is working correctly.   Could you try some variout things like
> putting 
> the p12 into the "current" directory and just setting the file attribute
> to 
> "test.eyeappts.com.p12".  Maybe the \ things are confusing it.     Not
> sure 
> what else to suggest at this point.
> 
> Dan
> 
> 
> On Thu February 11 2010 12:25:05 pm Jim Schneider wrote:
>> CXF 2.2.4 client trying to access an Axis2 soap web service over SSL
>> 
>> I can't get my CXF client to get past the SSL handshake, but the sample
>> Axis2 client from the web service developer works fine. Here's my config:
>> 
>>    <http:conduit name="*.http-conduit">
>> 
>> 	    <http:tlsClientParameters secureSocketProtocol="SSL"
>> disableCNCheck="true">
>> 	      <sec:keyManagers >
>> 	            <sec:keyStore type="PKCS12" password="testing"
>> file="C:\projects\hit-ws\Epp\test.eyeappts.com.p12"
>> 		    />
>> 	      </sec:keyManagers>
>> 	      <sec:trustManagers>
>> 				<sec:keyStore type="JKS" password="trustword"
>> 					file="C:\projects\hit-ws\Epp\truststore"
>> 				/>
>> 	      </sec:trustManagers>
>> 	      <sec:cipherSuitesFilter>
>> 			  <sec:include>.*{_}WITH_3DES{_}{*}*.*</sec:include>
>> 			  <sec:include>.*{_}EXPORT{_}{*}*.*</sec:include>
>> 			  <sec:include>.*{_}EXPORT1024{_}{*}*.*</sec:include>
>> 			  <sec:include>.*{_}WITH_DES{_}{*}*.*</sec:include>
>> 			  <sec:include>SSL_RSA_WITH_RC4_128_MD5</sec:include>
>> 			  <sec:include>SSL_RSA_WITH_RC4_128_SHA</sec:include>
>> 			  <sec:exclude>.*{_}WITH_NULL{_}{*}*.*</sec:exclude>
>> 			  <sec:exclude>.*{_}DH_anon{_}{*}*.*</sec:exclude>
>> 	      </sec:cipherSuitesFilter>
>> 	    </http:tlsClientParameters>
>>    </http:conduit>
>> 
>> I'm logging/tracing the SSL for both the successful Axis2 client and
>> unsuccessful CXF client and I see the ServerHelloDone message on both.
>> Then, on the Axis2 client, I see a "Certificate chain" message with a
>> single entry right before the ClientKeyExchange. On the CXF client, I see
>> the
>> "Certificate chain" header, but no entry.
>> 
>> Then, for the ClientKeyExchange, the Axis2 client sends 2 - 926 byte
>> messages, whereas the CXF client sends 2 - 141 byte messages. The Axis2
>> client finishes the SSL handshake successfully and moves on to the
>> application data. The CXF client has a failed handshake and then restarts
>> the ClientHello phase again.
>> 
>> I'm stuck. Any help is appreciated. I can send complete SSL outputs for
>> both if that would help.
> 
> -- 
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
> 
> 

-- 
View this message in context: http://old.nabble.com/CXF-client-SSL-pain-tp27551100p27554258.html
Sent from the cxf-user mailing list archive at Nabble.com.


Re: CXF client SSL pain

Posted by Daniel Kulp <dk...@apache.org>.

I'm not really sure what's happening.   Can you check the Client Hello token 
sent and make sure the cipher suites that are being sent to the server are OK?  
You cipherSuitesFilter thing looks a bit strange, but it just may be the mail 
client doing something.   Normally, they would look like:

<sec:include>.*_EXPORT_.*</sec:include>

without all the { and } thing in there.    That said, I would have still 
expected  a key to be sent of some sort so I'm not sure if the keyManager 
thing is working correctly.   Could you try some variout things like putting 
the p12 into the "current" directory and just setting the file attribute to 
"test.eyeappts.com.p12".  Maybe the \ things are confusing it.     Not sure 
what else to suggest at this point.

Dan


On Thu February 11 2010 12:25:05 pm Jim Schneider wrote:
> CXF 2.2.4 client trying to access an Axis2 soap web service over SSL
> 
> I can't get my CXF client to get past the SSL handshake, but the sample
> Axis2 client from the web service developer works fine. Here's my config:
> 
>    <http:conduit name="*.http-conduit">
> 
> 	    <http:tlsClientParameters secureSocketProtocol="SSL"
> disableCNCheck="true">
> 	      <sec:keyManagers >
> 	            <sec:keyStore type="PKCS12" password="testing"
> file="C:\projects\hit-ws\Epp\test.eyeappts.com.p12"
> 		    />
> 	      </sec:keyManagers>
> 	      <sec:trustManagers>
> 				<sec:keyStore type="JKS" password="trustword"
> 					file="C:\projects\hit-ws\Epp\truststore"
> 				/>
> 	      </sec:trustManagers>
> 	      <sec:cipherSuitesFilter>
> 			  <sec:include>.*{_}WITH_3DES{_}{*}*.*</sec:include>
> 			  <sec:include>.*{_}EXPORT{_}{*}*.*</sec:include>
> 			  <sec:include>.*{_}EXPORT1024{_}{*}*.*</sec:include>
> 			  <sec:include>.*{_}WITH_DES{_}{*}*.*</sec:include>
> 			  <sec:include>SSL_RSA_WITH_RC4_128_MD5</sec:include>
> 			  <sec:include>SSL_RSA_WITH_RC4_128_SHA</sec:include>
> 			  <sec:exclude>.*{_}WITH_NULL{_}{*}*.*</sec:exclude>
> 			  <sec:exclude>.*{_}DH_anon{_}{*}*.*</sec:exclude>
> 	      </sec:cipherSuitesFilter>
> 	    </http:tlsClientParameters>
>    </http:conduit>
> 
> I'm logging/tracing the SSL for both the successful Axis2 client and
> unsuccessful CXF client and I see the ServerHelloDone message on both.
> Then, on the Axis2 client, I see a "Certificate chain" message with a
> single entry right before the ClientKeyExchange. On the CXF client, I see
> the
> "Certificate chain" header, but no entry.
> 
> Then, for the ClientKeyExchange, the Axis2 client sends 2 - 926 byte
> messages, whereas the CXF client sends 2 - 141 byte messages. The Axis2
> client finishes the SSL handshake successfully and moves on to the
> application data. The CXF client has a failed handshake and then restarts
> the ClientHello phase again.
> 
> I'm stuck. Any help is appreciated. I can send complete SSL outputs for
> both if that would help.

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog