[
https://issues.apache.org/jira/browse/CXF-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13251390#comment-13251390
]
Freeman Fang commented on CXF-4233:
-----------------------------------
Hi,
We have a wsdl_first_https example shipped with CXF kit which demonstrate
clientAuthentication over https, the configration on server side is like
<sec:clientAuthentication want="true" required="true"/>
You need take a look at that example, it should be a good start for you.
Btw, IMO you should post this kind of question on cxf user mailling list first
but not create a jira issue directly here. Jira is in case that you're quite
sure it's a bug or some new feature/improvement you need, but not any problem
you run into when you use CXF.
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
> 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
