RAD/WAS SSL handshake errors when TLSv1.2 enabled
WAS
- QOP settings in WAS admin console
- Added com.ibm.ssl.protocol=TLSv1.2 to ssl.client.properties in the WAS profile
- Cleared temp files
RTC/RAD
- Added entries to eclipse.ini
-Dcom.ibm.team.repository.transport.client.protocol=TLSv1.2
-Djdk.tls.client.protocols=TLSv1.2
-Dhttps.protocols=TLSv1.2
- Added com.ibm.ssl.protocol=TLSv1.2 to ssl.client.properties in C:\Program Files\IBM\SDP\runtimes\base_stub\properties.
The WAS server actually does start when selecting Start through RAD/RTC, but the status never changes to started. I have to stop the server by running the usual stopserver command. It seems that something in the RTC/RAD environment is still trying to connect to WAS using TLSv1. I have verified that WAS is using TLSv1.2 when connecting with browsers.
Before the TLSv1.2 changes are made, RTC/RAD can stop/start the WAS server just fine. Currently, we have to be at RTC 5.0.2 since that what our servers are at and I'm not sure the infrastructure team will be upgrading any time soon.
I've been through most of the debug steps listed at http://www-01.ibm.com/support/docview.wss?uid=swg21266028. Currently checking on key length now, but I would have expected a different error if the key length was a problem.
Errors from WAS log:
[1/13/16 14:47:17:943 EST] 00000086 SSLHandshakeE E SSLC0008E: Unable to initialize SSL connection. Unauthorized access was denied or security settings have expired. Exception is javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1 not enabled or not supported
at com.ibm.jsse2.lb.B(lb.java:529)
at com.ibm.jsse2.SSLEngineImpl.b(SSLEngineImpl.java:91)
at com.ibm.jsse2.SSLEngineImpl.c(SSLEngineImpl.java:310)
at com.ibm.jsse2.SSLEngineImpl.wrap(SSLEngineImpl.java:505)
at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:16)
at com.ibm.ws.ssl.channel.impl.SSLUtils.handleHandshake(SSLUtils.java:747)
at com.ibm.ws.ssl.channel.impl.SSLConnectionLink.readyInbound(SSLConnectionLink.java:566)
at com.ibm.ws.ssl.channel.impl.SSLConnectionLink.ready(SSLConnectionLink.java:295)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:175)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138)
at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204)
at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1881)
Caused by: javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1 not enabled or not supported
at com.ibm.jsse2.p.a(p.java:36)
at com.ibm.jsse2.SSLEngineImpl.a(SSLEngineImpl.java:72)
at com.ibm.jsse2.lb.a(lb.java:44)
at com.ibm.jsse2.lb.a(lb.java:460)
at com.ibm.jsse2.nb.a(nb.java:455)
at com.ibm.jsse2.nb.a(nb.java:618)
at com.ibm.jsse2.lb.t(lb.java:241)
at com.ibm.jsse2.lb$1.run(lb$1.java:1)
at java.security.AccessController.doPrivileged(AccessController.java:452)
at com.ibm.jsse2.lb$c_.run(lb$c_.java:8)
at com.ibm.ws.ssl.channel.impl.SSLUtils.handleHandshake(SSLUtils.java:834)
Any ideas??
Thanks,
Mike
2 answers
If you have a Linux machine, openssl is a great tool to verify what protocols are available for a particular SSL connection.
If you don't want to spend too much time in troubleshooting this, you can use the WAS server as a "remote" server.
Comments
Hi Donald,
Thanks for the tips. I've checked all the stub entries in RAD (base_stub, base_v7_stub, base_v8_stub, base_v85_stub) and have made the changes to all of them, but the errors persist. I have verified the ssl.client.properties file on the WAS server side as well. We hook up RAD to the actual WAS install and don't use the RAD WAS stub. I have gotten this working with RAD 8.5 and WAS 8.0 as that is our current environment. TLSv1.2 is now required in our environment, so I have to get this figured out. Hopefully, we don't have to go to the full SP800-131 implementation to make TLSv1.2 work since that does not match our production environment.
I may try to connect a RAD 8.5 environment to the WAS 8.5 server and see what happens. I know RAD 8.5 can connect to our WAS 8.0 servers over TLSv1.2.
One other bit of information is that when I try to test the server connection within RAD, I get a failure on the SOAP connection. The ports do match on both ends and I have turned off the firewall for now. The error is ADMC0016E: The system cannot create a SOAP connector to connect to host localhost at port 8880. The odd thing is that there is nothing in the WAS logging that indicates a failed attempt to connect even when I have started WAS with trace on.
That's interesting. I found a machine with RAD 8.5 and WAS 8.5.0.0 and did not have any problems with the TLSv1.2 connection. I didn't even need to worry about stub at all. Everything just works.
What I tried is as follows.
1. Enable TLSv1.2 on WAS. Test is passed.
2. Add the three lines in eclipse.ini. Restart RAD. Test is passed.
3. Create three server definition using the RMI, SOAP and IPC protocol respectively, pointing to the same WAS profile. All three connect successfully and display the started and stopped status in synchronization.
The fact that you could not even connect with SOAP is very strange, as it should not be affected by TLSv1.2 at all.
Maybe you can try your luck with RMI?
In some of the reading I have been doing about the errors I am seeing, I have come across threads mentioning java SSL connection API calls being made with default connection settings may use TLSv1. This would explain what is happening. If there's some environment variable not being set in RAD, when it tries to connect to WAS, it's using default settings, which do not use TLSv1.2.