It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,882
×6,035

question asked: Jan 13 '16, 3:47 p.m.
question was seen: 11,526 times
last updated: Jan 15 '16, 9:05 a.m.

Related questions

RAD/WAS SSL handshake errors when TLSv1.2 enabled

0
Mike Orth (1●1●1●1) | asked Jan 13 '16, 3:47 p.m.
I have RAD 9.5.0.1 with RTC 5.0.2 iFix008 connected to a local WAS 8.5.5.8 instance.  When trying to start the WAS server within RAD, I get SSL errors.  I have configured the WAS and RAD/RTC environments with the proper TLSv1.2 changes:
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

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Donald Nong (14.5k●6●14) | answered Jan 13 '16, 8:28 p.m.
I haven't used RAD for many years so what I recall may not be accurate, or not suitable for latest versions of RAD, but here it goes. The WAS Server that you start within RAD should be a "stub" (or copy) of the actual server (the server profile that you create in the usual way), and its configuration is separate from the actual server. I suspect that you have not enabled TLSv1.2 for the stub server - you probably only enabled it for the actual server.

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
Mike Orth commented Jan 14 '16, 11:02 a.m. | edited Jan 14 '16, 1:09 p.m.

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.

Donald Nong commented Jan 15 '16, 2:55 a.m.

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?

0
permanent link
Mike Orth (1●1●1●1) | answered Jan 15 '16, 9:05 a.m.
I was able to make one of our existing RAD 8.5 environments connect to the WAS 8.5.5 instance, so it looks like there's something specific with RAD 9.5 that is different.  I know there is a soap.client.properties file.  Maybe that needs some changes as well?  I can't find any documentation stating that though. 

 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.

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.