[ 
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

        

Reply via email to