The Problem

The latest fixpacks for Tivoli Workload Scheduler have included sections which discuss the expiration of the default SSL certificates that most Tivoli Workload Automation components use. These certificates will expire on February 10, 2014 after which point, secure communications between key components of a TWS infrastructure will no longer work. At the time of writing, that gives a window of 11 months where steps must be taken by pretty much every implementation of TWS there is out there, to replace the expiring certificates with new, IBM-supplied versions which are good until November 2032.

How much or how little the expiration of the default certificates will affect your TWS environment is dependent on the components you use and how they’re secured, multiplied by the size of  your estate. If you have SSL-enabled Fault Tolerant Agents and have rolled out Dynamic Agents under a Dynamic Workload Broker and manage it all using the Tivoli Dynamic Workload Console, you will have a lot more work to do than someone still on TWS 8.4 who just uses the JSC to manage their batch.

This article focusses on TWS Distributed but there are implications for TWS for z/OS too. The affected versions are TWS 8.3, TWS 8.4, TWS 8.5 and TWS 8.6.  The affected components of a TWS infrastructure that need to have the default certificates replaced are:-

  1. Tivoli Dynamic Workload Console. TDWC servers that connect to a Master Domain Manager, a Backup Master Domain Manager or an agent with a Distributed Connector installed will need to have their certificates updated on all of the components.
  2. Job Scheduling Console. Users of TWS 8.3 and TWS 8.4 that still use the Job Scheduling Console will need to have the certificates on the JSC client replaced. If they are not replaced, the JSC will no longer work beyond February 2014. Enterprise users may not currently know how many JSC clients they have in their estate so a knowledge-gathering exercise should be undertaken as soon as possible to identify where they are and arange for the certificates to be replaced. Alternatively, JSC may be presented to your users via Citrix so this would need to be factored into a testing scenario.
  3. Dynamic Workload Broker, Managers and Agents. If you are using TWA’s dynamic scheduling capabilities, you will need to replace the certificates on all of your dynamic infrastructure including the Master Domain Manager, dynamic domain managers and backup dynamic domain managers as well as the dynamic agents themselves. Even if you don’t currently schedule dynamically, the dynamic agent is installed automatically in some agent installation configurations and the default certificates will have to be replaced eventually if you do plan on using dynamic scheduling at some point.
  4. SSL-enabled Networks. This one will be a biggie for some customers. If you just use regular Fault Tolerant Agents in your estate, the bulk of the remediation of the expiring certificates will need to be done on your management infrastructure and they agents themselves don’t need to be touched, assuming you don’t plan to do dynamic scheduling any time soon. If you have enabled SSL-communication between FTA – Domain Manager – Master Domain Manager, then you will need to replace the certificates on all of your FTAs too.
  5. Custom Integration using API/Integration Workbench. If you have built your own integration with TWS using the Integration Workbench over SSL or have by use the features of the published API, you will need to investigate the impact of certificate expiration.
  6. Remote Command-Line. The remote command-line utility communicates over HTTPS by default but there is an additional configuration element where you can use the certificate from Websphere on the MDM/BKM and utilise that with the RCLI. In the latter scenario, you would need to replace the expiring certificates.

What To Do Next

  • Read the IBM Flash Alerts for TWS Distributed and TWS for z/OS
  • Attend the Support Technical Exchange sessions which IBM will be holding in April – see the Flash Alert for details
  • Larger customers should use the 11-month head-start to review their environment and identify which components of their infrastructure would need to have their certificates updated and plan for the work to be carried out. While it’s easy to know which agents you have in your estate, it’s not always known where your Job Scheduling Console clients are installed if you use still use them.
  • If you’re intending to roll out new agents or planning an agent upgrade cycle, it would be worthwhile bearing the certificate implications in mind, but if there’s a driver such as this where you must visit every agent on your estate anyway, this could be used as an opportunuity to perform an upgrade to the latest version of the agent software, especially as new functionality such as Workload Service Assurance or Event Driven Workload Automation are reliant on the latest versions to be installed on all agents before they should be used.