Thursday, 1 October 2015

JSSL0080E: - 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: -

( 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 createSSLSocket ProcessDiscovery : 0 JSSL0080E: - 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. 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: -


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 ?

No comments:

SSH and "Too many authentication failures" - a new one on me

Having created a new user on an Ubuntu 16.04 boxen, I started seeing this: - Received disconnect from port 22:2: Too many au...