Impact DASH Console Integration broken by Fix Pack 22

I plan for this to be my shortest blog so far, with the single objective of sharing some technical information that might assist those installing Netcool Impact v7.1 Fix Pack 22.

I applied FP22 for Netcool Impact v7.1 yesterday and it broke the DASH Console Integration for Impact. No other patches were applied at the same time. IBM’s current release cycle for the core components for Netcool Operations Insight is roughly every 3 months, but the patch releases are not synchronised. At the end of June I’d updated all the core components for NOI to the latest available patches at the time, including:

  • Netcool OMNIbus Core to v8.1.0.25
  • Netcool OMNIbus Web GUI to 8.1.0.23
  • WebSphere Application Server 8.5.5.19
  • IBM Dashboard Application Services Hub 1.3.11
  • Netcool Impact 7.1.0.21

Unfortunately, Fix Pack 21 for Netcool Impact v7.1 broke the OMNIbus EventReader management of the event column ImpactFlag. Hence, the install of Fix Pack 22 following its recent release.

This time the fix pack install broke the DASH Console Integration for Impact, the feature that enables the Impact UI to be accessed from within DASH. This feature is very useful for cross product administration. The problem results in the Impact page disappearing from the “Integrations” folder, or whichever folder was selected in the “Console Integrations” settings for the Impact  integration (personally I add it to the Web GUI “Administration” folder, to group all the administration pages together).

The first check was to run the Console Integration “Test” from Console Settings >> Console Integrations and selecting the Console Integration configured for Impact. The test generated the error:

Status: Unable to connect to the remote console. Please check the console URL externally to ensure it works.

Not much information, so I loaded the Console Integration URL, i.e. URL for the Impact rest endpoint, directly in a browser. That loaded successfully.

The final debug step, that pointed to the underlying issue, was to view the Impact UI “console.log”, located in the path $IMPACT_HOME/wlp/usr/servers/ImpactUI/logs, as the test was executed. The key entry was:

[ERROR   ] CWWKO0801E: Unable to initialize SSL connection. Unauthorized access was denied or security settings have expired. Exception is javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1 is not enabled or supported in server context

My assumption here is that Fix Pack 22 for Impact v7.1 changed the accepted SSL protocols (a WAS Liberty Update?). So, my options were to re-configure Impact to accept TLSv1, or update WebSphere Application Server (the foundations for Jazz SM and DASH) to use an updated protocol. I chose the latter. From the WebSphere Administration Console for the DASH I updated the Protocol from SSL_TLS to TLSv1.2:

Security >> SSL Certificate and key management >> SSL configuration >> NodeDefaultSSLSettings >> Quality of protection (QoP) settings

Protocol: Changed from SSL_TLS > TLSv1.2

This resolved the test error, but introduced an issue running the Jazz SM script serverStatus, stopServer and startServer. Those scripts now reporting the error:

ADMU0509I: The Application Server “server1” cannot be reached. It appears to be stopped.

 

A similar protocol update was required to the Jazz SM file “ssl.client.props” in the path $JAZZSM/profile/properties. The property “com.ibm.ssl.protocol” was updated as follows:

#com.ibm.ssl.protocol=SSL_TLS

com.ibm.ssl.protocol=TLSv1.2

All now back-up and working. But why was the problem not mentioned in any of the IBM documentation? Similar updates are detailed in the Runbook Automation documents, but not the Impact v7.1 or Fix Pack documents.

Possibly the setting in my test environment has been inherited from the original installation, as this environment was first installed at near base levels and has been patched over several years? Maybe the WebSphere Application Server default SSL setting would be different for a fresh install? Possibly some security update has advised the change of SSL settings, but I’ve not applied it to my unloved test environment (although I know of many production environments that received significantly less attention than my test environment)?

I’ve not investigated those questions, but hopefully this blog will help anyone in a similar position.

Visits: 558