cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Freeman Fang (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-4233) cxf should improve ssl support
Date Wed, 11 Apr 2012 13:01:17 GMT

    [ https://issues.apache.org/jira/browse/CXF-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13251522#comment-13251522
] 

Freeman Fang commented on CXF-4233:
-----------------------------------

Hi,

I just run the wsdl_first_https example in 2.5.2 kit and it works for me, I'm quite sure the
https works in CXF.

And you mentioned before your configuration works when there's no clientAuthentication but
doesn't if enable clientAuthentication, so most likely you miss some configuration on your
client side, as the client side configuration should be different in these two cases.

Take a close look at the README.txt of wsdl_first_https example, this part

The client is configured to provide its certificate "CN=Wibble" and
chain stored in the Java KeyStore "certs/wibble.jks" to the server. The
server authenticates the client's certificate using its trust store
"certs/truststore.jks", which holds the Certificate Authorities'
certificates.

Likewise the client authenticates the server's certificate "CN=Cherry"
and chain against the same trust store.  Note also the usage of the
cipherSuitesFilter configuration in the configuration files,
where each party imposes different ciphersuites contraints, so that the
ciphersuite eventually negotiated during the TLS handshake is acceptable
to both sides. 

The key part is the client side also need authenticates the server's certificate "CN=Cherry",
it need client side configure the correct trust store which can validate the server's certificate.

You may need take a close look at the wsdl_first_https/bin/gencerts.sh which demonstrate how
to generate the keystore, truststore, and also show the relationship between them. It should
be a very good start for you if you're not familiar with those yet.

Finally, if you still have issues, please post your question on cxf user mailling list,  as
there is the right place to discuss this kind of question. Maybe elaborate your configuration
in both cases there, also the way how you generate the keystore/truststore which is very important.


Freeman
                
> cxf should improve ssl support
> ------------------------------
>
>                 Key: CXF-4233
>                 URL: https://issues.apache.org/jira/browse/CXF-4233
>             Project: CXF
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 2.5.2
>         Environment: windowx or linux with jdk1.6.22 or more
>            Reporter: jerryscott2012
>            Assignee: Freeman Fang
>              Labels: security
>             Fix For: 2.6
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> in my project, I publish my service under ssl like this :https://localhost:9090/CardWebServiceProvider
(in server side)
> and set ClientAuthentication with true (ClientAuthentication ca = new ClientAuthentication();ca.setRequired(true);
ca.setWant(true);)
> then I start my client side to access the service, here comes the exception
> Caused by: java.net.SocketException: SocketException invoking https://localhost:9090/CardWebServiceProvider:
Software caused connection abort: recv failed
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> 	at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1431)
> 	at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1416)
> 	at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> 	at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:649)
> 	at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> 	... 36 more
> Caused by: java.net.SocketException: Software caused connection abort: recv failed
> 	at java.net.SocketInputStream.socketRead0(Native Method)
> 	at java.net.SocketInputStream.read(SocketInputStream.java:129)
> 	at com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
> 	at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)
> 	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:798)
> 	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.waitForClose(SSLSocketImpl.java:1493)
> 	at com.sun.net.ssl.internal.ssl.HandshakeOutStream.flush(HandshakeOutStream.java:103)
> 	at com.sun.net.ssl.internal.ssl.Handshaker.sendChangeCipherSpec(Handshaker.java:689)
> 	at com.sun.net.ssl.internal.ssl.ClientHandshaker.sendChangeCipherAndFinish(ClientHandshaker.java:985)
> 	at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:904)
> 	at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:238)
> 	at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
> 	at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
> 	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:893)
> 	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138)
> 	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165)
> 	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1149)
> 	at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:434)
> 	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166)
> 	at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1019)
> 	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:230)
> 	at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleHeadersTrustCaching(HTTPConduit.java:1368)
> 	at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.onFirstWrite(HTTPConduit.java:1310)
> 	at org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:42)
> 	at org.apache.cxf.io.AbstractThresholdOutputStream.write(AbstractThresholdOutputStream.java:69)
> 	at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1388)
> 	... 39 more
> all my environment established resort to http://aruld.info/programming-ssl-for-jetty-based-cxf-services/
(what's more, I did import the truststore and keystore file into my browser and my server
root store keep in touch with them.)
> so could cxf team provide better solution to resolve it(or give some complete example
to introduce it) as once I set ClientAuthentication with true it threw the exception as above
or else it didn't. and surely I run the client problem with -Djavax.net.debug=all (seem that
the server verification close but client still wait the response)
> 		

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message