Thursday, 30 June 2016

WebSphere Application Server, TLS 1.2 and DB2

It's been a day for old blog posts helping to fix new problems.

Today, we saw this: -

CWSIS1593I: The messaging engine, ME_UUID=E997A9EFA09498FC, INC_UUID=6DC2A53AD19710D7, has failed to gain an initial lock on the data store.
CWSIS1538I: The messaging engine, ME_UUID=E997A9EFA09498FC, INC_UUID=6DC2A53AD19710D7, is attempting to obtain an exclusive lock on the data store.

which led me here: -

However the resolution - to sort out the SIB tables - did NOT help.

However we also saw this: -

MESSAGE : DIA3604E The SSL function "gsk_secure_soc_init" failed with the 
          return code "402" in "sqlccSSLSocketSetup".

in the DB2 diagnostic log.

This second post was of immense use: -

as it confirmed that rc402 means: -

0x00000192     402     GSK_ERROR_NO_CIPHERS     Neither SSLV2 nor SSLV3 is enabled.

We're using a Dynamic outbound endpoint SSL configuration set up between WAS and DB2, which ensures that specific connections, on specific ports, go via a specific SSL Configuration, and use TLS 1.2 and strong SSL ciphers.

This is an interim fix, before we enable TLS 1.2 and the strong ciphers across the entire WAS cell.

For some yet-to-be-unexplained reason, even though we had the fully-qualified hostname ( host plus domain ) of the DB2 servers, something was forcing WAS to use the short-name ( hostname ) instead.

Of course, the Dynamic SSL configuration was ONLY configured for the FQDN, and NOT for the short-name.

Once the short-names of the DB2 boxes ( we have an HADR pair ) was applied, WAS worked a treat.

Easy when you know how ….

No comments: