Thursday, 1 October 2015

JSSL0080E: javax.net.ssl.SSLHandshakeException - The client and server could not negotiate the desired level of security

How does the song go ? "Oops, I did it again" ?

I'd previously blogged about this problem a few months back: -


Well, yesterday I went through the process of enabling Transport Layer Security (TLS) 1.2 as the default SSL/TLS protocol within a WAS 8.5.5 cell ( hosting IBM ODM Advanced 8.7 for the record ).

This is the command that I ran: -

AdminTask.modifySSLConfig('[-alias CellDefaultSSLSettings -scopeName (cell):odm87Cell1 -keyStoreName CellDefaultKeyStore -keyStoreScopeName (cell):odm87Cell1 -trustStoreName CellDefaultTrustStore -trustStoreScopeName (cell):odm87Cell1 -jsseProvider IBMJSSE2 -sslProtocol TLSv1.2 -clientAuthentication false -clientAuthenticationSupported false -securityLevel HIGH -enabledCiphers ]')

 I then saved and synced the cell: -

AdminConfig.save()
AdminNodeManagement.syncActiveNodes()


( The Deployment Manager and two Node Agents were already running )

I then found that the nodes failed to connect to the Deployment Manager, and I saw: -

[30/09/15 15:42:21:934 BST] 000000c7 ORBRas        E com.ibm.ws.security.orbssl.WSSSLClientSocketFactoryImpl createSSLSocket ProcessDiscovery : 0 JSSL0080E: javax.net.ssl.SSLHandshakeException - The client and server could not negotiate the desired level of security.  Reason: Server chose TLSv1, but that protocol version is not enabled or not supported by the client. javax.net.ssl.SSLHandshakeException: Server chose TLSv1, but that protocol version is not enabled or not supported by the client.

Using my prior experience, I immediately checked the security.xml file at the node level i.e. on each of the two nodes: -

/opt/ibm/WebSphereProfiles/ODMCell1AppSrv01/config/cells/odm87Cell1/security.xml

Lo and behold, I saw: -

>     <setting xmi:id="SecureSocketLayer_1" clientAuthentication="false" securityLevel="HIGH" enabledCiphers="" jsseProvider="IBMJSSE2" sslProtocol="SSL_TLS" keyStore="KeyStore_1" trustStore="KeyStore_2" trustManager="TrustManager_2" keyManager="KeyManager_1">

whereas I should've seen: -

<     <setting xmi:id="SecureSocketLayer_1" clientAuthentication="false" securityLevel="HIGH" enabledCiphers="" jsseProvider="IBMJSSE2" sslProtocol="TLSv1.2" keyStore="KeyStore_1" trustStore="KeyStore_2" trustManager="TrustManager_2" keyManager="KeyManager_1">

I manually edited the file on each of the two nodes, and restarted the Node Agent on each.

Once done, the nodes started happily, connected to the Deployment Manager without problems, and allowed me to perform a FULL synchronisation of the entire cell.

The moral of the story ?

When I ran the AdminTask.modifySSLConfig command, I should've run the command to perform a FULL synch. of the cell.

Guess what I'll do next time ?

2 comments:

Syed Aamer Saeed said...

Hi,
I am running WAS(8.0.0.7) with Business Monitor on AIX enviroment. I did see the same error in dmgr logs when trying start the DMGR. Althought dmgr started but same errors are showing in the logs... I did manually change the security.xml file but even ten no success. Any idea?

Dave Hay said...

Hey Syed

Thanks for the comment - this is a 6 year-old post, so things may well have changed, especially since WAS 7 has gone out of service a while back afaik.

Bottom line, compare/contrast security.xml on both the Deployment Manager and the WAS Node(s).

It's almost certainly going to be a config error, so you're on the right track.

Good luck, Dave

Note to self - use kubectl to query images in a pod or deployment

In both cases, we use JSON ... For a deployment, we can do this: - kubectl get deployment foobar --namespace snafu --output jsonpath="{...