You can enable jvm level TLS debug: -Djavax.net.debug=all See this site for more information: http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/ReadDebug.html
Dave Tauzell | Senior Software Engineer | Surescripts O: 651.855.3042 | www.surescripts.com | dave.tauz...@surescripts.com Connect with us: Twitter I LinkedIn I Facebook I YouTube -----Original Message----- From: David Sills [mailto:dsi...@datasourceinc.com] Sent: Tuesday, January 12, 2016 12:52 PM To: Tomcat Users List Subject: RE: Problem with clientAuth SSL connection One question as I try this - how to get logging at the debug level for the handshake process? I have tried setting everything in logging.properties to FINEST, but it makes no difference. -----Original Message----- From: David Sills [mailto:dsi...@datasourceinc.com] Sent: Tuesday, January 12, 2016 1:30 PM To: Tomcat Users List Subject: RE: Problem with clientAuth SSL connection I will try both sides in Java 8. Our client, however, still has to use Java 6 (government.... sigh...). But at least if the same problem occurs, I'll know what's going on. And I'll check the certificates, though I was exceedingly careful during the setup and checked everything once already. -----Original Message----- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Tuesday, January 12, 2016 12:23 PM To: Tomcat Users List Subject: Re: Problem with clientAuth SSL connection Mark, On 1/12/16 12:01 PM, Mark Thomas wrote: > On 12/01/2016 16:39, David Sills wrote: >> Oh, and by the way, it turns out I'm using Java 6, not 8. Not that that >> should make a huge difference, but our client is a bit behind the times. > > Are you sure the right certs are in the right stores? > > If all the certs are self-signed then: > > The trust store used by the client must include the server's cert. > The trust store used by the server must include the client's cert. > > In isn't clear (to me anyway) form your original post what certs are > in what stores. > > There should be no limits on using self-signed certs but with old Java > 6 and Java 8 you might hit an issue with general SSL compatibility. If > it works without a client cert then you should be OK. Good thought: Java 6 doesn't speak TLS 1.1/1.2 and (recent) Java 8 will refuse to negotiate SSLv3. So there may be a protocol issue going on. David, is there a reason you can't run your client using Java 8? That might remove some of the guesswork. -chris >> -----Original Message----- >> From: David Sills [mailto:dsi...@datasourceinc.com] >> Sent: Tuesday, January 12, 2016 11:35 AM >> To: Tomcat Users List >> Subject: RE: Problem with clientAuth SSL connection >> >> Christopher: >> >> Thank you for your prompt reply. >> >> The client does seem to need a trust store when dealing with a self-signed >> certificate from the server, as otherwise it tries to create a chain back to >> an implicitly trusted CA. I agree, with a commercial certificate this would >> not be necessary, as such a chain would be available. I prefer to separate >> the keystores (the one for the client and the one for the server) on both >> sides. I was hoping that the trust store would work the same in Tomcat as it >> does in the client (which does work, as I said, perfectly when only >> validating one-way) - whatever was in it would be implicitly trusted without >> checking for a certificate chain. >> >> This message seems to say that the server is shutting down the handshake >> connection just when the client is about to send its certificate, but >> perhaps I'm misinterpreting it. >> >> Another possibility: perhaps self-signed certificates aren't allowed for >> client authentication on the server side? >> >> David >> >> >> >> -----Original Message----- >> From: Christopher Schultz [mailto:ch...@christopherschultz.net] >> Sent: Tuesday, January 12, 2016 11:02 AM >> To: Tomcat Users List >> Subject: Re: Problem with clientAuth SSL connection >> >> David, >> >> On 1/12/16 7:43 AM, David Sills wrote: >>> All: >>> >>> I'm trying to set up clientAuth SSL connection between a batch process and >>> Tomcat (7.0.55, Java 8 64-bit server). One-way SSL works wonderfully. I set >>> up a server certificate (self-signed) and used this configuration in Tomcat >>> (server.xml): >>> >>> <Connector port="${https.port}" >>> protocol="org.apache.coyote.http11.Http11Protocol" >>> maxThreads="150" SSLEnabled="true" scheme="https" >>> secure="true" sslProtocol="TLS" >>> keystoreFile="conf/dsikeystore.jks" >>> keystorePass="keystorePassword" >>> clientAuth="false" >>> /> >>> >>> In the client, I used >>> >>> java -cp ws-client.jar >>> -Djavax.net.ssl.trustStore=clientkeystore2.jks >>> -Djavax.net.ssl.trustStorePassword=changeme >>> com.datasourceinc.abis.ws.pds.ServiceClient >>> >>> It seemed to me pretty straightforward that to set up client >>> authentication, I would need to >>> >>> >>> 1. Generate another (self-signed) certificate >>> >>> 2. Export that certificate to a *.crt file >>> >>> 3. Create another keystore on the server >>> >>> 4. Import the certificate from #2 >>> >>> 5. Mark that in the configuration as the trust store >>> >>> So, >>> >>> <Connector port="${https.port}" >>> protocol="org.apache.coyote.http11.Http11Protocol" >>> maxThreads="150" SSLEnabled="true" scheme="https" >>> secure="true" sslProtocol="TLS" >>> keystoreFile="conf/dsikeystore.jks" >>> keystorePass="keystorePassword" >>> clientAuth="true" >>> truststoreFile="conf/clienttrustkeystore.jks" >>> truststorePass="changeme" >>> /> >> >> Pretty much, yes. >> >>> And change the client (which has the original self-signed >>> certificate) thus >>> >>> java -cp ws-client.jar -Djavax.net.ssl.keyStore=clientkeystore.jks >>> -Djavax.net.ssl.keyStorePassword=changeme >>> -Djavax.net.ssl.trustStore=clientkeystore2.jks >>> -Djavax.net.ssl.trustStorePassword=changeme >>> com.datasourceinc.abis.ws.pds.ServiceClient >> >> No, the client doesn't need a trust store. The client needs to specify the >> keystore where the client certificate exists. Also, the client needs to know >> which key to present to the server. Is the client you are using known to >> work correctly? I'm tempted to recommend that you use another tool known to >> do client-certs correctly, just in case your home-brewed tool is not doing >> what it should. >> >>> >>> All keystores have been verified. >>> >>> I have to have done something wrong or missed a step, because I keep >>> butting up against this error, even after having tried all the fixes I read >>> online, including restarting my (Windows 7) machine and of course >>> restarting the server: >>> >>> java.net.SocketException: Software caused connection abort: recv failed >>> at java.net.SocketInputStream.socketRead0(Native Method) >>> at java.net.SocketInputStream.read(Unknown Source) >>> at java.net.SocketInputStream.read(Unknown Source) >>> at sun.security.ssl.InputRecord.readFully(Unknown Source) >>> at sun.security.ssl.InputRecord.read(Unknown Source) >>> at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source) >>> at sun.security.ssl.SSLSocketImpl.waitForClose(Unknown Source) >>> at sun.security.ssl.HandshakeOutStream.flush(Unknown Source) >>> at sun.security.ssl.Handshaker.sendChangeCipherSpec(Unknown Source) >>> at >>> sun.security.ssl.ClientHandshaker.sendChangeCipherAndFinish(Unknown Source) >>> at sun.security.ssl.ClientHandshaker.serverHelloDone(Unknown Source) >>> at sun.security.ssl.ClientHandshaker.processMessage(Unknown Source) >>> at sun.security.ssl.Handshaker.processLoop(Unknown Source) >>> at sun.security.ssl.Handshaker.process_record(Unknown Source) >>> at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source) >>> at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown >>> Source) >>> at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) >>> at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) >>> at >>> org.apache.axis.components.net.JSSESocketFactory.create(JSSESocketFactory.java:186) >>> at >>> org.apache.axis.transport.http.HTTPSender.getSocket(HTTPSender.java:191) >>> at >>> org.apache.axis.transport.http.HTTPSender.writeToSocket(HTTPSender.java:404) >>> at >>> org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:138 >>> ) >>> >>> at >>> org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32) >>> at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118) >>> at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83) >>> at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165) >>> at org.apache.axis.client.Call.invokeEngine(Call.java:2784) >>> at org.apache.axis.client.Call.invoke(Call.java:2767) >>> at org.apache.axis.client.Call.invoke(Call.java:2443) >>> at org.apache.axis.client.Call.invoke(Call.java:2366) >>> at org.apache.axis.client.Call.invoke(Call.java:1812) >>> at >>> com.datasourceinc.abis.ws.pds.server.generated.IRS_PDS_ABIS_ServiceSOAP12BindingStub.update(IRS_PDS_ABIS_ServiceSOAP12BindingStub.java:164) >>> at >>> com.datasourceinc.abis.ws.pds.PdsServiceClient.main(PdsServiceClient >>> .j >>> ava:47) >>> >>> {http://xml.apache.org/axis/}hostname:DSI-DEV03 >>> >>> java.net.SocketException: Software caused connection abort: recv failed >>> at org.apache.axis.AxisFault.makeFault(AxisFault.java:101) >>> at >>> org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:154 >>> ) >>> >>> at >>> org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32) >>> at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118) >>> at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83) >>> at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165) >>> at org.apache.axis.client.Call.invokeEngine(Call.java:2784) >>> at org.apache.axis.client.Call.invoke(Call.java:2767) >>> at org.apache.axis.client.Call.invoke(Call.java:2443) >>> at org.apache.axis.client.Call.invoke(Call.java:2366) >>> at org.apache.axis.client.Call.invoke(Call.java:1812) >>> at >>> com.datasourceinc.abis.ws.pds.server.generated.IRS_PDS_ABIS_ServiceSOAP12BindingStub.update(IRS_PDS_ABIS_ServiceSOAP12BindingStub.java:164) >>> at >>> com.datasourceinc.abis.ws.pds.PdsServiceClient.main(PdsServiceClient >>> .j >>> ava:47) Caused by: java.net.SocketException: Software caused >>> connection abort: recv failed >>> at java.net.SocketInputStream.socketRead0(Native Method) >>> at java.net.SocketInputStream.read(Unknown Source) >>> at java.net.SocketInputStream.read(Unknown Source) >>> at sun.security.ssl.InputRecord.readFully(Unknown Source) >>> at sun.security.ssl.InputRecord.read(Unknown Source) >>> at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source) >>> at sun.security.ssl.SSLSocketImpl.waitForClose(Unknown Source) >>> at sun.security.ssl.HandshakeOutStream.flush(Unknown Source) >>> at sun.security.ssl.Handshaker.sendChangeCipherSpec(Unknown Source) >>> at >>> sun.security.ssl.ClientHandshaker.sendChangeCipherAndFinish(Unknown Source) >>> at sun.security.ssl.ClientHandshaker.serverHelloDone(Unknown Source) >>> at sun.security.ssl.ClientHandshaker.processMessage(Unknown Source) >>> at sun.security.ssl.Handshaker.processLoop(Unknown Source) >>> at sun.security.ssl.Handshaker.process_record(Unknown Source) >>> at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source) >>> at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown >>> Source) >>> at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) >>> at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) >>> at >>> org.apache.axis.components.net.JSSESocketFactory.create(JSSESocketFactory.java:186) >>> at >>> org.apache.axis.transport.http.HTTPSender.getSocket(HTTPSender.java:191) >>> at >>> org.apache.axis.transport.http.HTTPSender.writeToSocket(HTTPSender.java:404) >>> at >>> org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:138 >>> ) >>> >>> ... 11 more >>> >>> Does anyone have any ideas that might help? >> -chris >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org This e-mail and any files transmitted with it are confidential, may contain sensitive information, and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please notify the sender by reply e-mail immediately and destroy all copies of the e-mail and any attachments.
