As mentioned in an earlier post: -
IBM HTTP Server, Transport Layer Security and Google Chrome
I've been working through the configuration of Transport Layer Security (TLS) 1.2 between DB2 and WebSphere Application Server (WAS).
I've learned a heck of a lot about this in the past 48 hours, but the key aspect is that it's necessary to configure BOTH DB2 *AND* WAS to support TLS 1.2.
For DB2, this is relatively simple; it requires that the DB2 instance(s) have their Database Manager Configuration updated, specifically via this DBM configuration: -
SSL versions (SSL_VERSIONS) = TLSV12
via the command: -
db2 update dbm config using SSL_VERSIONS TLSV12
before restarting the DBM: -
db2stop
db2start
However, I then started seeing: -
2015-05-29-08.29.15.785836+060 I6227180E484 LEVEL: Error
PID : 2889 TID : 139639469893376 PROC : db2sysc 0
INSTANCE: db2inst1 NODE : 000
APPHDL : 0-4765
HOSTNAME: bam856.uk.ibm.com
EDUID : 20 EDUNAME: db2agent () 0
FUNCTION: DB2 UDB, common communication, sqlccMapSSLErrorToDB2Error, probe:30
MESSAGE : DIA3604E The SSL function "gsk_secure_soc_init" failed with the
return code "402" in "sqlccSSLSocketSetup".
in my DB2 log ( /home/db2inst1/sqllib/db2dump/db2diag.log ).
After much digging about, I found that rc402 means: -
0x00000192 402 GSK_ERROR_NO_CIPHERS Neither SSLV2 nor SSLV3 is enabled.
This led me to think that WAS wasn't using that particular version of SSL/TLS.
After much digging about, I realised that it's a relatively simple change; one needs to change the Quality of Protection (QoP) settings for the WAS cell, via: -
SSL certificate and key management > SSL configurations > CellDefaultSSLSettings > Quality of protection (QoP) settings
or via a Jython script: -
AdminTask.modifySSLConfig('[-alias CellDefaultSSLSettings -scopeName (cell):BAMCell1 -keyStoreName CellDefaultKeyStore -keyStoreScopeName (cell):BAMCell1 -trustStoreName CellDefaultTrustStore -trustStoreScopeName (cell):BAMCell1 -jsseProvider IBMJSSE2 -sslProtocol TLSv1.2 -clientAuthentication false -clientAuthenticationSupported false -securityLevel HIGH -enabledCiphers ]')
AdminConfig.save()
AdminNodeManagement.syncActiveNodes()
This did lead to an interesting glitch. Having updated the cell configuration, and saved, the sync failed, leaving the node in a bad state.
Looking at the Node agent logs ( nodeagent/SystemOut.log ), I saw: -
[30/05/15 19:24:08:649 BST] 000001b6 FileTransferC E ADFS0112E: File transfer has failed with the following message: Download retry limit exceeded for retrieving url
bam856.uk.ibm.com:9043/FileTransfer/tran...
[30/05/15 19:24:08:655 BST] 000001b6 FileDocument E ADMR0105E: The system is unable to write document cells/BAMCell1/security.xml: java.io.FileNotFoundException: File download failed: java.io.IOException: Error occurred during download from: download/cells/BAMCell1/security.xml1616272729083741357.tmp. Exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
at com.ibm.websphere.management.filetransfer.client.FileDownloadInputStream.getStream(FileDownloadInputStream.java:230)
at com.ibm.websphere.management.repository.RepositoryInputStream.read(RepositoryInputStream.java:137)
at java.security.DigestInputStream.read(DigestInputStream.java:173)
at java.io.FilterInputStream.read(FilterInputStream.java:118)
at com.ibm.ws.management.repository.FileDocument.copyDocument(FileDocument.java:452)
at com.ibm.ws.management.repository.FileDocument.write(FileDocument.java:295)
at com.ibm.ws.management.repository.FileRepository.modifyInternal(FileRepository.java:1274)
at com.ibm.ws.management.repository.FileRepository.updateInternal(FileRepository.java:1512)
at com.ibm.ws.management.repository.FileRepository.update(FileRepository.java:1417)
at com.ibm.ws.management.repository.FileRepository.modify(FileRepository.java:1193)
at com.ibm.ws.management.repository.FileRepository.modify(FileRepository.java:1184)
at com.ibm.ws.management.sync.NodeSyncTask.processFolderSyncUpdate(NodeSyncTask.java:472)
at com.ibm.ws.management.sync.NodeSyncTask.doSync(NodeSyncTask.java:283)
at com.ibm.ws.management.sync.NodeSyncTask.run(NodeSyncTask.java:157)
at java.lang.Thread.run(Thread.java:801)
To "fix" this, I needed to manually edit the Node security.xml: -
/opt/IBM/WebSphere/AppServer/profiles/BAMCell1AppSrv01/logs/nodeagent
/config/cells/BAMCell1/security.xml
and change: -
sslProtocol="SSL_TLS"
to: -
sslProtocol="TLSv1.2"
which brought it into unison with the cell version of security.xml: -
/opt/IBM/WebSphere/AppServer/profiles/BAMCell1Dmgr01/config/cells/BAMCell1/security.xml
Once I made this change, and manually restarted the Node Agent, all was well, and both Deployment Manager and Node Agent were correctly using TLS 1.2.
The only additional thing I needed to do was remember to actually set DB2 to use TLS 1.2 :-)
Prior to this final change, I saw this: -
The test connection operation failed for data source Monitor_Admin_Database on server dmgr at node Dmgr with the following exception: java.sql.SQLNonTransientException: [jcc][t4][2030][11211][4.18.60] A communication error occurred during operations on the connection's underlying socket, socket input stream, or socket output stream. Error location: Reply.fill() - socketInputStream.read (-1). Message: Server chose TLSv1.1, but that protocol version is not enabled or not supported by the client.. ERRORCODE=-4499, SQLSTATE=08001 DSRA0010E: SQL State = 08001, Error Code = -4,499. View JVM logs for further details.
Once I "fixed" DB2, all was well.
I now have WAS talking to DB2 via TLS 1.2, which is nice.
One thing about which I need to think ... I've configured WAS to use TLS 1.2. That means that ALL SSL/TLS connections will use this particular SSL/TLS version - FOR EVERYTHING.
Therefore, I need to ensure that everything connecting to and from WAS can support TLS 1.2. Whilst I know that modern browsers such as Chrome and Firefox can, I need to check various versions of Internet Explorer, AND check downstream connections, such as LDAP ( Active Directory 2008 ) etc.
Which is nice :-)