renewing default certificates for tivoli workload scheduler

IBM Tivoli Workload Scheduler

Renewing default certificates for TivoliWorkload SchedulerVersion 8.3.0 8.4.0 8.5.0 8.5.1 8.6.0

��

NoteBefore using this information and the product it supports, read the information in “Notices” on page 75.

Contents

Chapter 1. Scenarios affected by defaultcertificates expiration . . . . . . . . . 1Scenarios for the distributed environment . . . . 1

Scenario: Connection between the DynamicWorkload Console and agent with a distributedconnector . . . . . . . . . . . . . . 2Scenario: Connection between the Job SchedulingConsole and agent with a distributed connector . 2Scenario: Connection among dynamic agents andthe master domain manager or dynamic domainmanager . . . . . . . . . . . . . . . 2Scenario: SSL Communication across the TivoliWorkload Scheduler network . . . . . . . . 3Scenario: Custom integration based on TivoliWorkload Scheduler Java APIs . . . . . . . 4Scenario: Integration Workbench over SSL . . . 4Scenario: HTTPS for the command-line clients . . 4

Scenarios for distributed components in a z/OSenvironment . . . . . . . . . . . . . . 4

Scenario: Connection between the DynamicWorkload Console and the z/OS connector in adistributed system . . . . . . . . . . . 5Scenario: Connection between the Job SchedulingConsole and the z/OS connector on a distributedsystem . . . . . . . . . . . . . . . 5Scenario: Connection between Tivoli WorkloadScheduler for z/OS agent (z-centric agent) andz/OS Controller . . . . . . . . . . . . 5Scenario: Connection among dynamic domainmanagers and the z/OS Controller . . . . . . 6

Chapter 2. How to renew the defaultcertificates . . . . . . . . . . . . . 7Downloading the package . . . . . . . . . . 7Installing the package . . . . . . . . . . . 8

Package contents . . . . . . . . . . . . 8Scripts to renew the default certificates . . . . . 9

updTrustStoreCerts . . . . . . . . . . . 9updKeyStoreCerts . . . . . . . . . . . 12

updTrustKeyStoreCerts . . . . . . . . . 15Procedure to renew the default certificates in adistributed environment . . . . . . . . . . 16

Procedure to manage the default truststore formaster domain manager, backup master domainmanager, and agents with distributed connector . 18Procedure to manage the default truststore andkeystore for the Dynamic Workload Console andJob Scheduling Console . . . . . . . . . 23Procedure to manage the default certificates fordynamic scheduling environment . . . . . . 28Procedure to manage the default certificates forfault-tolerant agents and domain managers in theSSL environment . . . . . . . . . . . 38Procedure to manage the default certificates forthe connector APIs . . . . . . . . . . . 47Procedure to manage the default certificates forthe Integration Workbench . . . . . . . . 48Procedure to manage the default truststore andkeystore for command-line client . . . . . . 49Procedure to manage the default keystore formaster domain manager, backup master domainmanager, and agents with distributed connector . 52

Procedure to renew the default certificates fordistributed components used in a z/OSenvironment . . . . . . . . . . . . . . 57

Procedure to renew the default certificates forz/OS connector on a distributed system . . . . 57Procedure to manage the default certificates forTivoli Workload Scheduler for z/OS agent(z-centric) . . . . . . . . . . . . . . 69Procedure to manage the default certificates fordynamic domain managers connected to thez/OS Controller . . . . . . . . . . . . 73

Notices . . . . . . . . . . . . . . 75Trademarks . . . . . . . . . . . . . . 76

Index . . . . . . . . . . . . . . . 79

iii

iv Renewing default certificates

Chapter 1. Scenarios affected by default certificates expiration

Tivoli Workload Scheduler provides a secure, authenticated, and encryptedconnection mechanism for communication based on the Secure Sockets Layer (SSL)protocol, which is automatically installed with Tivoli Workload Scheduler.

Tivoli Workload Scheduler also provides default certificates to manage the SSLprotocol that is based on a private and public key methodology.

The following terminology is used:

truststoreIn security, a storage object, either a file or a hardware cryptographic card,where public keys are stored in the form of trusted certificates, forauthentication purposes in web transactions. In some applications, thesetrusted certificates are moved into the application keystore to be storedwith the private keys.

keystoreIn security, a file or a hardware cryptographic card where identities andprivate keys are stored, for authentication and encryption purposes. Somekeystores also contain trusted or public keys.

If you do not customize SSL communication with your own certificates, TivoliWorkload Scheduler uses the default certificates that are stored in the defaultdirectories to communicate in SSL mode.

The default certificates that were released with Tivoli Workload Scheduler V8.3.0, V8.4.0,V8.5.0, V8.5.1, and V8.6.0 general availability expire on February 10, 2014.

If Tivoli Workload Scheduler uses the default certificates for SSL connections, theadministrator must renew the default certificates for the following scenariosbecause they are affected by the expiration date:v “Scenarios for the distributed environment.”v “Scenarios for distributed components in a z/OS environment” on page 4.

Make sure that you update the default certificates in the correct order for thesescenarios. For more information about how to do this, see Chapter 2, “How torenew the default certificates,” on page 7.

Scenarios for the distributed environmentThe following scenarios for the distributed environment are affected by theexpiration date:v “Scenario: Connection between the Dynamic Workload Console and agent with a

distributed connector” on page 2v “Scenario: Connection between the Job Scheduling Console and agent with a

distributed connector” on page 2v “Scenario: Connection among dynamic agents and the master domain manager

or dynamic domain manager” on page 2v “Scenario: SSL Communication across the Tivoli Workload Scheduler network”

on page 3

1

v “Scenario: Custom integration based on Tivoli Workload Scheduler Java APIs”on page 4

v “Scenario: Integration Workbench over SSL” on page 4v “Scenario: HTTPS for the command-line clients” on page 4

Your environment might include one or more of these scenarios. For moreinformation about how to update the default certificates in the correct order forthese scenarios, see “Procedure to renew the default certificates in a distributedenvironment” on page 16.

Scenario: Connection between the Dynamic Workload Consoleand agent with a distributed connector

The SSL communication between the Dynamic Workload Console and one of thefollowing types of Tivoli Workload Scheduler component is affected by theexpiration date of the default certificates:v Master domain manager.v Backup master domain manager.v Agent with distributed connector.

If you do not modify the default certificates on the Dynamic Workload Consoleand on the distributed connector installed on the agent before the expiration date,the communication between the user interface and the connector is broken. In theTivoli Workload Scheduler distributed environment, you can manage the TivoliWorkload Scheduler database objects and plan objects using the composer andconman commands.

Scenario: Connection between the Job Scheduling Consoleand agent with a distributed connector

The SSL communication between the Job Scheduling Console and one of thefollowing types of Tivoli Workload Scheduler component is affected by theexpiration date of the default certificates:v Master domain manager.v Backup master domain manager.v Agent with distributed connector.

If you do not modify the default certificates on the Job Scheduling Console and onthe distributed connector installed on the agent before the expiration date, thecommunication between the user interface and the connector is broken. In theTivoli Workload Scheduler distributed environment, you can manage the TivoliWorkload Scheduler database objects and plan objects using the composer andconman commands.

Scenario: Connection among dynamic agents and the masterdomain manager or dynamic domain manager

The default certificates provided during Tivoli Workload Scheduler installation,ensure the secure connection between the following componenets:v Master domain manager and dynamic domain manager or backup dynamic

domain manager.v Master domain manager and dynamic agents.v Dynamic domain manager and dynamic agents.

2 Renewing default certificates

v Dynamic domain manager and backup dynamic domain manager.

The SSL communication between the Broker Server installed on the master domainmanager and one of the following components is affected by the expiration date ofthe default certificates:v Dynamic agents.v Dynamic domain managers.v Backup dynamic domain managers.v Agent installed as default in the master domain manager.v

If you do not modify the default certificates in the Broker server installed on thedynamic domain manager and on the dynamic agents before the expiration date,the communication between the dynamic domain manager and the dynamic agentsis broken.

The communication between the ResourceCLI command line installed on thedynamic domain manager and the Broker Server installed on the master domainmanager is also broken.

Note:

v The dynamic domain manager and backup dynamic domain managercomponents are included in V8.6.0 and later.

v On Windows, UNIX, and Linux operating systems, the dynamic agentcomponent is included in V8.5.1 and later. On IBM i operating systems, thedynamic agent component is included in V8.6.0.

Scenario: SSL Communication across the Tivoli WorkloadScheduler network

You can enable the SSL connection using OpenSSL Toolkit for the followingcomponents:v Master domain manager and its domain managersv Master domain manager and fault-tolerant agents in the master domainv Master domain manager and backup master domain managerv Domain manager and fault-tolerant agents that belong to that domain

The SSL communication among agents V8.4.0, V8.5.0, V8.5.1, or V8.6.0 with relatedfix packs in the network is affected by the expiration date of the defaultcertificates.

If the version of the Tivoli Workload Scheduler instance is V8.4.0 or an upgrade ofV8.4.0 and related fix packs, the default certificates are located in the<INSTALL_DIR>\TWS\ssl\sslDefault directory; in other cases the default certificatesare located in the <INSTALL_DIR>\TWS\ssl\OpenSSL directory.

All Tivoli Workload Scheduler administrators who use the OpenSSL defaultcertificates for SSL communication must modify the certificates to maintain aworking SSL environment.

Chapter 1. Scenarios affected by default certificates expiration 3

Note: The default GSKit certificates expiration date is not the "February 10, 2014"and administrators are not required to perform any recovery actions. Checkperiodically the GSKit certificates expiration date to keep the default certificatesup-to-date.

Scenario: Custom integration based on Tivoli WorkloadScheduler Java APIs

If you have an SSL connection that uses default certificates in a custom integrationbased on Tivoli Workload Scheduler Java APIs V8.3.0, V8.4.0, V8.5.0, V8.5.1, orV8.6.0 with related fix packs, the communication does not work after the defaultcertificates expiration date.

Scenario: Integration Workbench over SSLIntegration Workbench is used to develop custom plug-ins.

If you have an SSL connection that uses default certificates for the IntegrationWorkbench V8.4.0, V8.5.0, V8.5.1, or V8.6.0 with related fix packs, thecommunication does not work after the default certificates expiration date.

Scenario: HTTPS for the command-line clientsYou can have one of the following scenarios:v If you have an SSL connection that uses default certificates between the

command-line utilities (composer and conman) on the master domain managerand the connector:

The variable CLISSLSERVERAUTH=no in the master domain managerlocalopts file

The communication continues to work after the default certificatesexpiration date.

The variable CLISSLSERVERAUTH=yes in the master domain managerlocalopts file

The communication does not work after the default certificatesexpiration date.

v If you have an SSL connection that uses default certificates between the remotecommand-line client and the master domain manager:

The variable CLISSLSERVERAUTH=no in the remote command-line clientlocalopts file

The communication continues to work after the default certificatesexpiration date.

The variable CLISSLSERVERAUTH=yes in the remote command-line clientlocalopts file

The communication does not work after the default certificatesexpiration date.

Scenarios for distributed components in a z/OS environmentThe following scenarios for distributed components in a z/OS environment areaffected by the expiration date:v “Scenario: Connection between the Dynamic Workload Console and the z/OS

connector in a distributed system” on page 5.v “Scenario: Connection between the Job Scheduling Console and the z/OS

connector on a distributed system” on page 5.


v “Scenario: Custom integration based on Tivoli Workload Scheduler Java APIs”on page 4

v “Scenario: Integration Workbench over SSL” on page 4v “Scenario: Connection between Tivoli Workload Scheduler for z/OS agent

(z-centric agent) and z/OS Controller.”v “Scenario: Connection among dynamic domain managers and the z/OS

Controller” on page 6

Note: You might have one or more of these scenarios previously described. Toupdate default certificates in the correct order for these scenarios, see “Procedureto renew the default certificates for distributed components used in a z/OSenvironment” on page 57.

Scenario: Connection between the Dynamic Workload Consoleand the z/OS connector in a distributed system

The SSL communication between the Dynamic Workload Console and the z/OSconnector installed in a distributed system is affected by the expiration date of thedefault certificates.

If you do not modify the default certificates on the Dynamic Workload Consoleand the z/OS connector before the expiration date, the communication between theuser interface and the connector is broken.

In a Tivoli Workload Scheduler z/OS environment, you can manage the databaseobjects and plan objects by using ISPF panels.

Scenario: Connection between the Job Scheduling Consoleand the z/OS connector on a distributed system

The SSL communication between the Job Scheduling Console and the z/OSconnector installed in a distributed system is affected by the expiration date of thedefault certificates.

If you do not modify the default certificates on the Job Scheduling Console and thez/OS connector before the expiration date, the communication between the userinterface and the connector is broken.

In a Tivoli Workload Scheduler z/OS environment, you can manage the databaseobjects and plan objects by using ISPF panels.

Scenario: Connection between Tivoli Workload Scheduler forz/OS agent (z-centric agent) and z/OS Controller

The SSL communication between the z/OS Controller and the z-centric agent isaffected by the expiration date of the default certificates.

If you do not modify the default certificates on the z/OS Controller and on thez-centric agent before the expiration date, the communication between the z/OSController and the z-centric agent is broken.

Note: On Windows, UNIX, and Linux operating systems, the z-centric agentcomponent is included in V8.5.1 and later. On IBM i operating systems, thez-centric agent component is included in V8.6.0.

Chapter 1. Scenarios affected by default certificates expiration 5

Scenario: Connection among dynamic domain managers andthe z/OS Controller

The SSL communication between the z/OS Controller and the dynamic domainmanagers is affected by the expiration date of the default certificates.

If you do not modify the default certificates on the z/OS Controller and on thedynamic domain managers before the expiration date, the communication betweenthe z/OS Controller and the dynamic domain managers is broken.

Note: The dynamic domain manager and backup dynamic domain managercomponents are included in V8.6.0 and later.


Chapter 2. How to renew the default certificates

The default certificates released with the Tivoli Workload Scheduler V8.3.0, V8.4.0,V8.5.0, V8.5.1, and V8.6.0 general availability components expire on February 10,2014.

Tivoli Workload Scheduler provides a package that contains new defaultcertificates and a set of scripts that you use to modify the old default certificateswith the new ones, for each of the following versions at each level of fix pack:v V8.3.0

v V8.4.0

v V8.5.0

v V8.5.1

v V8.6.0

For more information about how to download the package for the version youneed to install, see “Downloading the package.”

Downloading the packageTo download the package, perform the following procedure:1. Go to IBM Fix Central support site.2. Select Tivoli as Product Group.3. Select Tivoli Workload Scheduler as Select from Tivoli.4. Depending on the version of the Tivoli Workload Scheduler component you

need to manage, select the package you want to download:

Tivoli Workload Scheduler component V8.3.08.3.0-TIV-TWA-CERTIFICATES





5. Download the package you selected into the <PACKAGE_INSTALL_DIR> genericdirectory.

The package contains the following .zip file:

Package V8.3.0updCertsScripts_v830.zip



7



Installing the packageAfter you downloaded the package into the generic <PACKAGE_INSTALL_DIR>directory, as described in “Downloading the package” on page 7, to install thepackage, perform the following procedure:1. Extract the content of the updCertsScripts_v<VERSION_NUMBER>.zip file into the

<PACKAGE_INSTALL_DIR> directory, where <VERSION_NUMBER> is the version of theTivoli Workload Scheduler component installed where you need to manage thedefault certificates.

2. On UNIX operating systems, to give the correct read and write access to allfiles in the directory <PACKAGE_INSTALL_DIR>, run the following command:chmod -R 755 <PACKAGE_INSTALL_DIR>

For more information about the package contents, see “Package contents.”

Package contentsIf you installed the package as described in “Installing the package,” you have thecontents of the .zip file in the following directory:

On Windows operating systems<PACKAGE_INSTALL_DIR>\updCertsScripts_v<VERSION_NUMBER>

On UNIX, Linux, and IBM i operating systems/<PACKAGE_INSTALL_DIR>/updCertsScripts_v<VERSION_NUMBER>

wherev <PACKAGE_INSTALL_DIR> is the package installation directory.v <VERSION_NUMBER> is the version of the Tivoli Workload Scheduler installed.

The installation directory contains the following files and directories:v New directory that contains new defaults certificatesv Old directory that contains old defaults certificatesv Scripts to manage new and old certificates:

On Windows operating systems

– updTrustStoresCerts.bat

– updKeyStoresCerts.bat

– updTrustKeyStoresCerts.bat

On UNIX, Linux, and IBM i operating systems

– updTrustStoresCerts.sh

– updKeyStoresCerts.sh

– updTrustKeyStoresCerts.sh

For more information about scripts, see “Scripts to renew the default certificates”on page 9.


Scripts to renew the default certificatesThe package provides a set of scripts that you use to manage and update the TivoliWorkload Scheduler truststore and Tivoli Workload Scheduler keystore related tothe default certificates:v “updTrustStoreCerts.”v “updKeyStoreCerts” on page 12.v “updTrustKeyStoreCerts” on page 15.

updTrustStoreCertsThe updTrustStoreCerts script checks the truststore in the default SSL location forthe current instance of Tivoli Workload Scheduler. If the default truststore is used,the script updates the contents and the final truststore is the concatenation of theold truststore and the new truststore.

After modifying the truststore, if you do not immediately update the keystore forthe default certificates, all the communication scenarios described in Chapter 1,“Scenarios affected by default certificates expiration,” on page 1, continue to workuntil the expiration date.

If you store your own truststore in the SSL default directory, the installationprocess does not modify the truststore contents. The installation process checks ifthe checksum of the certificate is the checksum of the default certificate released atgeneral availability time.

The script saves the default truststore old certificates with a .bck extension.

Note:

v Run the script only when no Tivoli Workload Scheduler instance processes arerunning.

v Run the script as Administrator on Windows operating systems, root on UNIXand Linux operating systems, and QSECOFR user on IBM i operating systems.

On Windows operating systems:

The script syntax is:updTrustStoresCerts.bat "<INSTALL_DIR>"

where <INSTALL_DIR> is the installation directory of the selected instanceof Tivoli Workload Scheduler.

The script installs the following new files:

V8.3.0

v <INSTALL_DIR>\AppServer\profiles\<PROFILENAME>\etc\TWSServerTrustFile.jks

v <INSTALL_DIR>\AppServer\profiles\<PROFILENAME>\etc\TWSClientTrustFile.jks

where <PROFILENAME> is:v twsprofile for master domain manager or backup master domain

manager.v twsconnprofile for distributed connector.

V8.4.0

Chapter 2. How to renew the default certificates 9

v <INSTALL_DIR>\AppServer\profiles\<PROFILENAME>\etc\TWSServerTrustFile.jks

v <INSTALL_DIR>\AppServer\profiles\<PROFILENAME>\etc\TWSClientTrustFile.jks

v <INSTALL_DIR>\ssl\sslDefault\TWSCertificateChainFile.pem



V8.5.0

v <INSTALL_DIR>\eWAS\profiles\twaprofile\etc\TWSServerTrustFile.jks

v <INSTALL_DIR>\eWAS\profiles\twaprofile\etc\TWSClientTrustFile.jks

v <INSTALL_DIR>\TWS\ssl\OpenSSL\TWSTrustCertificates.cer

v <INSTALL_DIR>\TWS\ssl\sslDefault\TWSCertificateChainFile.pem

V8.5.1

v <INSTALL_DIR>\eWAS\profiles\twaprofile\etc\TWSServerTrustFile.jks

v <INSTALL_DIR>\eWAS\profiles\twaprofile\etc\TWSClientTrustFile.jks

v <INSTALL_DIR>\TDWB_CLI\certs\TWSClientTrustFile.jks

v <INSTALL_DIR>\TWS\ITA\bin\TWSClientKeyStore.kdb


v <INSTALL_DIR>\TWS\ssl\sslDefault\TWSCertificateChainFile.pem

V8.6.0

v <INSTALL_DIR>\eWAS\profiles\TIPProfile\etc\TWSServerTrustFile.jks

v <INSTALL_DIR>\eWAS\profiles\TIPProfile\etc\TWSClientTrustFile.jks

v <INSTALL_DIR>\TDWB_CLI\certs\TWSClientTrustFile.jks

v <INSTALL_DIR>\TWS\ITA\cpa\ita\cert\TWSClientKey Store.kdb


v <INSTALL_DIR>\TWS\ssl\sslDefault\TWSCertificateChainFile.pem (if the Tivoli Workload Scheduleris upgraded from version 8.4.0 and related FixPacks)

The script also updates the <INSTALL_DIR>\TDWB\config\BrokerWorkstation.properties file to include the new CommonName value in the default truststore certificate that is ServerNew.

On UNIX operating systems:

The script syntax is:./updTrustStoresCerts.sh <INSTALL_DIR>




V8.3.0

v <INSTALL_DIR>/AppServer/profiles/<PROFILENAME>/etc/TWSServerTrustFile.jks

v <INSTALL_DIR>/AppServer/profiles/<PROFILENAME>/etc/TWSClientTrustFile.jks



V8.4.0

v <INSTALL_DIR>/AppServer/profiles/<PROFILENAME>/etc/TWSServerTrustFile.jks

v <INSTALL_DIR>/AppServer/profiles/<PROFILENAME>/etc/TWSClientTrustFile.jks

v <INSTALL_DIR>/ssl/sslDefault/TWSCertificateChainFile.pem



V8.5.0

v <INSTALL_DIR>/eWAS/profiles/twaprofile/etc/TWSServerTrustFile.jks

v <INSTALL_DIR>/eWAS/profiles/twaprofile/etc/TWSClientTrustFile.jks

v <INSTALL_DIR>/TWS/ssl/OpenSSL/TWSTrustCertificates.cer

v <INSTALL_DIR>/TWS/ssl/sslDefault/TWSCertificateChainFile.pem

V8.5.1

v <INSTALL_DIR>/eWAS/profiles/twaprofile/etc/TWSServerTrustFile.jks

v <INSTALL_DIR>/eWAS/profiles/twaprofile/etc/TWSClientTrustFile.jks

v <INSTALL_DIR>/TDWB_CLI/certs/TWSClientTrustFile.jks

v <INSTALL_DIR>/TWS/ITA/TWSClientKeyStore.kdb


v <INSTALL_DIR>/TWS/ssl/sslDefault/TWSCertificateChainFile.pem

V8.6.0

v <INSTALL_DIR>/eWAS/profiles/TIPProfile/etc/TWSServerTrustFile.jks

v <INSTALL_DIR>/eWAS/profiles/TIPProfile/etc/TWSClientTrustFile.jks

v <INSTALL_DIR>/TDWB_CLI/certs/TWSClientTrustFile.jks

v <INSTALL_DIR>/TWS/ITA/cpa/ita/cert/TWSClientKey Store.kdb



v <INSTALL_DIR>/TWS/ssl/sslDefault/TWSCertificateChainFile.pem (if the Tivoli Workload Scheduleris upgraded from version 8.4.0 and related fix pack)

The script also updates the <INSTALL_DIR>/TDWB/config/BrokerWorkstation.properties file to include the new CommonName value in the default truststore certificate which is ServerNew.

On IBM i operating systems:

The script syntax is:./updTrustStoresCerts.sh <INSTALL_DIR>


The script installs the following new file:

V8.3.0, V8.4.0, V8.5.0, and V8.5.1Not applicable.

V8.6.0

v <INSTALL_DIR>/TWS/ITA/cpa/ita/cert/ita_ca_certtws.pem

If you installed Tivoli Workload Scheduler V8.6.0 in the default directory, you run:

On Windows operating systems:updTrustStoresCerts.bat "C:\Program Files\IBM\TWA"

On UNIX, Linux, and IBM i operating systems:./updTrustStoresCerts.sh /opt/IBM/TWA

updKeyStoreCertsThe updKeyStoreCerts script checks the keystore in the default SSL location for thecurrent instance of Tivoli Workload Scheduler. If the default keystore is used, thescript backs up the old keystore contents and adds the new keystore contents.

The script saves the old certificates with a .bck extension.

Note:




The script syntax is:updateKeyStoresCerts.bat "<INSTALL_DIR>"



V8.3.0

v <INSTALL_DIR>\AppServer\profiles\<PROFILENAME>\etc\TWSServerKeyFile.jks

v <INSTALL_DIR>\AppServer\profiles\<PROFILENAME>\etc\TWSClientKeyFile.jks




V8.4.0

v <INSTALL_DIR>\AppServer\profiles\<PROFILENAME>\etc\TWSServerKeyFile.jks

v <INSTALL_DIR>\AppServer\profiles\<PROFILENAME>\etc\TWSClientKeyFile.jks

v <INSTALL_DIR>\ssl\sslDefault\TWSPrivateKeyFile.pem

v <INSTALL_DIR>\ssl\sslDefault\TWSPublicKeyFile.pem



V8.5.0

v <INSTALL_DIR>\eWAS\profiles\twaprofile\etc\TWSServerKeyFile.jks

v <INSTALL_DIR>\eWAS\profiles\twaprofile\etc\TWSClientKeyFile.jks

v <INSTALL_DIR>\TWS\ssl\OpenSSL\TWSClient.key

v <INSTALL_DIR>\TWS\ssl\OpenSSL\TWSClient.cer

v <INSTALL_DIR>\TWS\ssl\sslDefault\TWSPrivateKeyFile.pem

v <INSTALL_DIR>\TWS\ssl\sslDefault\TWSPublicKeyFile.pem

V8.5.1

v <INSTALL_DIR>\eWAS\profiles\twaprofile\etc\TWSServerKeyFile.jks

v <INSTALL_DIR>\eWAS\profiles\twaprofile\etc\TWSClientKeyFile.jks

v <INSTALL_DIR>\TDWB_CLI\certs\TWSClientKeyFile.jks

v <INSTALL_DIR>\TWS\ITA\bin\TWSClientKeyStore.kdb





V8.6.0

v <INSTALL_DIR>\eWAS\profiles\TIPProfile\etc\TWSServerKeyFile.jks

v <INSTALL_DIR>\eWAS\profiles\TIPProfile\etc\TWSClientKeyFile.jks

v <INSTALL_DIR>\TDWB_CLI\certs\TWSClientKeyFile.jks

v <INSTALL_DIR>\TWS\ITA\cpa\ita\cert\TWSClientKey Store.kdb






On UNIX and Linux operating systems:

The script syntax is:./updKeyStoresCerts.sh <INSTALL_DIR>



V8.3.0

v <INSTALL_DIR>/AppServer/profiles/<PROFILENAME>/etc/TWSServerKeyFile.jks

v <INSTALL_DIR>/AppServer/profiles/<PROFILENAME>/etc/TWSClientKeyFile.jks



V8.4.0

v <INSTALL_DIR>/AppServer/profiles/<PROFILENAME>/etc/TWSServerKeyFile.jks

v <INSTALL_DIR>/AppServer/profiles/<PROFILENAME>/etc/TWSClientKeyFile.jks

v <INSTALL_DIR>/ssl/sslDefault/TWSPrivateKeyFile.pem

v <INSTALL_DIR>/ssl/sslDefault/TWSPublicKeyFile.pem



V8.5.0

v <INSTALL_DIR>/eWAS/profiles/twaprofile/etc/TWSServerKeyFile.jks

v <INSTALL_DIR>/eWAS/profiles/twaprofile/etc/TWSClientKeyFile.jks

v <INSTALL_DIR>/TWS/ssl/OpenSSL/TWSClient.key

v <INSTALL_DIR>/TWS/ssl/OpenSSL/TWSClient.cer

v <INSTALL_DIR>/TWS/ssl/sslDefault/TWSPrivateKeyFile.pem

v <INSTALL_DIR>/TWS/ssl/sslDefault/TWSPublicKeyFile.pem

V8.5.1

v <INSTALL_DIR>/eWAS/profiles/twaprofile/etc/TWSServerKeyFile.jks

v <INSTALL_DIR>/eWAS/profiles/twaprofile/etc/TWSClientKeyFile.jks

v <INSTALL_DIR>/TDWB_CLI/certs/TWSClientKeyFile.jks

v <INSTALL_DIR>/TWS/ITA/TWSClientKeyStore.kdb






V8.6.0

v <INSTALL_DIR>/eWAS/profiles/TIPProfile/etc/TWSServerKeyFile.jks

v <INSTALL_DIR>/eWAS/profiles/TIPProfile/etc/TWSClientKeyFile.jks

v <INSTALL_DIR>/TDWB_CLI/certs/TWSClientKeyFile.jks

v <INSTALL_DIR>/TWS/ITA/cpa/ita/cert/TWSClientKey Store.kdb









V8.3.0, V8.4.0, V8.5.0, and V8.5.1Not applicable.

V8.6.0

v <INSTALL_DIR>/TWS/ITA/cpa/ita/cert/ita_prvtws.pem

v <INSTALL_DIR>/TWS/ITA/cpa/ita/cert/ita_certtws.pem

v <INSTALL_DIR>/TWS/ITA/cpa/ita/cert/ita_pubtws.pem


On Windows operating systems:updateKeyStoresCerts.bat "C:\Program Files\IBM\TWA"

On UNIX, Linux, and IBM i operating systems:./updateKeyStoresCerts.sh /opt/IBM/TWA

updTrustKeyStoreCertsThe updTrustKeyStoreCerts script runs first the updTrustStoresCerts and then theupdKeyStoresCerts scripts to update the truststore and the keystore.

The script saves the old certificates with a .bck extension.

Note:




The script syntax is:updateTrustKeyStoresCerts.bat "<INSTALL_DIR>"


where <INSTALL_DIR> is the installation directory of the selected instanceof Tivoli Workload Automation.

For a list of the files affected by this script, see the list for theupdTrustStoresCerts and the updKeyStoresCerts scripts.

On UNIX and Linux operating systems:





The script syntax is:./updTrustKeyStoresCerts.sh <INSTALL_DIR>




On Windows operating systems:updateTrustKeyStoresCerts.bat "C:\Program Files\IBM\TWA"

On UNIX, Linux, and IBM i operating systems:./updateTrustKeyStoresCerts.sh /opt/IBM/TWA

Procedure to renew the default certificates in a distributedenvironment

To modify the default certificates for the scenarios described in “Scenarios for thedistributed environment” on page 1, follow the steps listed in Figure 1 on page 17.

You do not need to update your Tivoli Workload Scheduler environment with thefollowing procedure steps all at the same time, but you must perform the entireprocedure before the certificates expire on February 10, 2014.


Procedure to renew the default certificates in a distributed environment

procedure default truststore for MDM,BKM, agents with dist connector

procedureDynamic environment

procedureSSL network

procedureconnector APIs

proceduresdk

procedureCLIs

procedure default keystore for MDM,BKM, agents with dist connector

YES YES

YES YES YES

NO NO NO

NO NONO

NO

BEGIN

END

YES

YES

YES

at least one default certificateused in the MDM?

NO

?

Dynamic environmentwith default certificates?

?

SSL across networkwith default certificates?

?

connector APIs withdefault certificates?

?

Integration Workbench withdefault certificates?

CLIs withdefault certificates?

?


?

At least one of theprevious procedures

performed?

LEGENDA:MDM master domain managerBKM backup master domain managerDWC Dynamic Workload ConsoleJSC Job Scheduling ConsoleCLI command-line client

?

DWC or JSC withdefault certificates?

procedureDWC/JSC

Figure 1. Procedure to renew the default certificates in a distributed environment


For each step in the list of procedures, if you have the described configuration,perform the procedure and then proceed with the successive step:1. If you use the default certificates in the master domain manager, perform the

“Procedure to manage the default truststore for master domain manager,backup master domain manager, and agents with distributed connector.”

2. If you have the Dynamic Workload Console or Job Scheduling Consoleconfigured over SSL with the default certificates, perform the “Procedure tomanage the default truststore and keystore for the Dynamic Workload Consoleand Job Scheduling Console” on page 23.

3. If you have the dynamic environment configured in SSL with the defaultcertificates, perform the“Procedure to manage the default certificates fordynamic scheduling environment” on page 28.

4. If you have the SSL communication enabled in Tivoli Workload Schedulerenvironment with OpenSSL default certificates, perform the “Procedure tomanage the default certificates for fault-tolerant agents and domain managersin the SSL environment” on page 38.

5. If you use the connector APIs with the default certificates, perform the“Procedure to manage the default certificates for the connector APIs” on page47.

6. If you use the Integration Workbench with the default certificates, perform the“Procedure to manage the default certificates for the Integration Workbench”on page 48.

7. If you use the command lines with the default certificates, perform the“Procedure to manage the default truststore and keystore for command-lineclient” on page 49.

8. If you performed any of the procedures listed in the steps 1 to 7, perform the“Procedure to manage the default keystore for master domain manager, backupmaster domain manager, and agents with distributed connector” on page 52.

Procedure to manage the default truststore for master domainmanager, backup master domain manager, and agents withdistributed connector


Procedure to manage the default truststore for master domain manager, backupmaster domain manager, and agents with distributed connector

1. To modify the master domain manager truststore, perform the followingactions:a. Log on as Administrator on Windows operating systems, or as root on

UNIX and Linux operating systems, on the machine where the masterdomain manager is installed.

?

Is BKM installed?NO

BEGIN

YES

?

Are agents installedwith dist connector ?

NO

YES

END

1. Modify the ruststoreMDM t

2. Modify the BKM truststore

3. Modify the agents withconnector truststore

Legenda:MDM master domain managerBKM backup master domain manager

Figure 2. Procedure to manage the default truststore for master domain manager, backup master domain manager,and agents with distributed connector


b. Download the version of the package that you need, as described in“Downloading the package” on page 7.

c. Install the package, as described in “Installing the package” on page 8.d. Stop the master domain manager by running:

If the master domain manager you installed is V8.3.0 with related fixpacks

On Windows operating systems:conman "stop"conman "shut; wait"stopWas.cmd

On UNIX and Linux operating systems:conman "stop"conman "shut; wait"stopWas

If the master domain manager you installed is V8.4.0, V8.5.0, V8.5.1, andV8.6.0 with related fix packs

On Windows, UNIX, and Linux operating systems:conman "stop"conman "stopmon"conman "stopappserver"conman "shut; wait"

For more information about the command syntax, see User's Guide andReference.

e. Modify the truststore by running:

For the master domain manager V8.3.0, V8.4.0, V8.5.0, V8.5.1, and V8.6.0with related fix packs:

On Windows operating systems:updTrustStoresCerts.bat

On UNIX and Linux operating systems:updTrustStoresCerts.sh

For more information about the command syntax, see“updTrustStoreCerts” on page 9.

f. Start the master domain manager by running:


On Windows operating systems:conman "start"startWas.cmd

On UNIX and Linux operating systems:conman "start"startWas.sh


On Windows, UNIX, and Linux operating systems:conman "start"conman "startmon"conman "startappserver"



2. If the backup master domain manager is installed, to modify the backup masterdomain manager truststore, perform the following actions:a. Log on as Administrator on Windows operating systems, or as root on

UNIX and Linux operating systems, on the machine where the backupmaster domain manager is installed.


c. Install the package, as described in “Installing the package” on page 8.d. Stop the backup master domain manager by running:

If the backup master domain manager you installed is V8.3.0 with relatedfix packs



If the backup master domain manager you installed is V8.4.0, V8.5.0,V8.5.1, and V8.6.0 with related fix packs

On Window, UNIX, and Linux operating systems:conman "stop"conman "stopmon"conman "stopappserver"conman "shut; wait"



For backup master domain manager V8.3.0, V8.4.0, V8.5.0, V8.5.1, andV8.6.0 with related fix packs




f. Start the backup master domain manager by running:



On UNIX and Linux operating systems:conman "start"startWas




3. Modify the truststore for the agents with distributed connector by performingthe following steps for each type of workstation with static scheduling anddistributed connectors:a. Log on as Administrator on Windows operating systems, or as root on

UNIX and Linux operating systems, on the machine where the agent isinstalled.


c. Install the package, as described in “Installing the package” on page 8.d. Stop the agent with distributed connector by running:

If the agent with distributed connector you installed is V8.3.0 with relatedfix packs



If the agent with distributed connector you installed is V8.4.0, V8.5.0,V8.5.1, and V8.6.0 with related fix packs

On Windows operating systems:conman "stop"conman "stopmon"conman "shut; wait"stopWas.bat

On UNIX and Linux operating systems:conman "stop"conman "stopmon"conman "shut; wait"stopWas



For agent with distributed connector V8.3.0, V8.4.0, V8.5.0, V8.5.1, andV8.6.0 with related fix packs




f. Start the agent with distributed connector by running:





If the agent you installed is V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with relatedfix packs

On Windows operating systems:conman "start"conman "startmon"startWas.bat

On UNIX and Linux operating systems:conman "start"conman "startmon"startWas

For more information about the command syntax, see User's Guideand Reference.

Procedure to manage the default truststore and keystore forthe Dynamic Workload Console and Job Scheduling Console

To manage the default certificates for user interfaces, for each step in the list,perform the procedure and then proceed with the successive step:1. If the Dynamic Workload Console is installed and works with default

certificates as described in “Scenario: Connection between the DynamicWorkload Console and agent with a distributed connector” on page 2, run“Procedure to manage the default truststore and keystore for the DynamicWorkload Console.”

2. If the Job Scheduling Console is installed and works with default certificates asdescribed in “Scenario: Connection between the Job Scheduling Console andagent with a distributed connector” on page 2, run “Procedure to manage thedefault truststore and keystore for the Job Scheduling Console” on page 27.

Procedure to manage the default truststore and keystore for theDynamic Workload Console


Procedure to manage the default truststore and keystore for the DynamicWorkload Console

1. Download and install the package by performing the following actions:a. Log on as Administrator on Windows operating systems, or as root on

UNIX and Linux operating systems, on the machine where the DynamicWorkload Console is installed.


c. Install the package, as described in “Installing the package” on page 8.2. Stop the WebSphere Application Server of the Dynamic Workload Console by

running:

On Windows operating systems:stopWas.bat

On UNIX and Linux operating systems:stopWas.sh

BEGIN

END

Legenda:DWC Dynamic Workload Console

1. Download and install the package

2. Stop the DWC

5. Start the DWC

3. Modify the DWC truststore

4. Modify the eystoreDWC k

Figure 3. Procedure to manage the default truststore and keystore for the Dynamic Workload Console


For more information about the command syntax, see Tivoli Workload Scheduler:Administration Guide > Administrative tasks > Application Server tasks.

3. Modify the truststore by running:



For more information about the command syntax , see “updTrustStoreCerts” onpage 9.

4. Modify the keystore by running:

On Windows operating systems:updKeyStoresCerts.bat

On UNIX and Linux operating systems:updKeyStoresCerts.sh

For more information about the command syntax, see “updKeyStoreCerts” onpage 12.

5. Start the Dynamic Workload Console by running:

On Windows operating systems:startWas.bat

On UNIX and Linux operating systems:startWas.sh


Note for Dynamic Workload Console V8.6 or later users:

Note: For Dynamic Workload Console V8.6 or later, after you run the procedure,when you stop the WebSphere Application Server for the first time, you are askedto accept the new client truststore for the Dynamic Workload Console. Follow theprocedure “Accepting the new Dynamic Workload Console truststore when youstop the WebSphere Application Server for the first time.”

Accepting the new Dynamic Workload Console truststore when you stop theWebSphere Application Server for the first time:After you run the “Procedure to manage the default truststore and keystore for theDynamic Workload Console” on page 23, when you stop the WebSphereApplication Server for the first time, you are asked to accept the new clienttruststore for the Dynamic Workload Console.

To accept the new truststore during the running of stopWas.bat on Windowsoperating systems and stopWas.sh on UNIX and Linux operating systems, reply"y" to the prompt Add signer to the trust store now? (y/n).

On UNIX and LINUX operating systems:

If you stop the WebSphere Application Server for the first time on UNIXand Linux operating systems, by running the stopWas.sh script, you havethe following output:# ./stopWas.sh -direct -user twsuser -password twsuserADMU0116I: Tool information is being logged in file/opt/ibm/TWATDWC/eWAS/profiles/TIPProfile/logs/server1/stopServer.log


ADMU0128I: Starting tool with the TIPProfile profileADMU3100I: Reading configuration for server: server1

*** SSL SIGNER EXCHANGE PROMPT ***SSL signer from target host 9.168.125.188 is not found in trust store/opt/ibm/TWATDWC/eWAS/profiles/TIPProfile/etc/TWSClientTrustFile.jks.

Here is the signer information(verify the digest value matches what is displayed at the server):

Subject DN: CN=ServerNew, OU=TWS, O=IBM, C=USIssuer DN: CN=ServerNew, OU=TWS, O=IBM, C=USSerial number: 1352882899Expires: Tue Nov 09 09:48:19 CET 2032SHA-1 Digest: 5D:16:5D:17:3B:5F:BF:B7:EA:19:92:22:2D:36:53:1A:2F:9D:1B:26MD5 Digest: DB:BA:A2:6D:0D:B6:A2:53:35:6D:32:6A:40:20:D5:36Add signer to the trust store now? (y/n)yA retry of the request may need to occur if the socket times outwhile waiting for a prompt response.If the retry is required, note thatthe prompt will not be redisplayed if is entered,which indicates the signer has already been added to the trust store.ADMU3201I: Server stop request issued. Waiting for stop status.ADMU4000I: Server server1 stop completed.


If you stop the WebSphere Application Server for the first time onWindows operating systems, by running the stopWas.bat script from thewastools directory, you have the following output:C:\TWA2\wastools>stopWas.batThe service is running.Service failed to stop. stopServer return code -10

Run the stopWas.bat from the embedded WebSphere Application Serverbinary directory and you have the following output:C:\TWA2\eWAS\bin>stopServer.bat server1ADMU0116I: Tool information is being logged in fileC:\TWA2\eWAS\profiles\TIPProfile\logs\server1\stopServer.logADMU0128I: Starting tool with the TIPProfile profileADMU3100I: Reading configuration for server: server1

*** SSL SIGNER EXCHANGE PROMPT ***SSL signer from target host 9.168.125.163 is not found in trust storeC:/TWA2/eWAS/profiles/TIPProfile/etc/TWSClientTrustFile.jks.


Subject DN: CN=ServerNew, OU=TWS, O=IBM, C=USIssuer DN: CN=ServerNew, OU=TWS, O=IBM, C=USSerial number: 1352882899Expires: Mon Nov 08 20:48:19 GMT-12:00 2032SHA-1 Digest: 5D:16:5D:17:3B:5F:BF:B7:EA:19:92:22:2D:36:53:1A:2F:9D:1B:26MD5 Digest: DB:BA:A2:6D:0D:B6:A2:53:35:6D:32:6A:40:20:D5:36

Add signer to the trust store now? (y/n)yA retry of the request may need to occur if the socket times outwhile waiting for a prompt response.If the retry is required, note that the prompt will not be redisplayed if is entered,which indicates the signer has already been added to the trust store.ADMU3201I: Server stop request issued. Waiting for stop status.ADMU4000I: Server server1 stop completed.


Procedure to manage the default truststore and keystore for theJob Scheduling Console

Procedure to manage the default truststore and keystore for the Job SchedulingConsole


UNIX and Linux operating systems, on the machine where the JobScheduling Console is installed.


c. Install the package, as described in “Installing the package” on page 8.2. Stop the Job Scheduling Console by closing the wizard.3. Modify the truststore by copying the <PACKAGE_INSTALL_DIR>\TWS\

updCertsScripts\New\PUBLIC\JSC\JSCDefaultTrustFile.jks file to the directory<JSC_INSTALL_DIR>\keys where the <PACKAGE_INSTALL_DIR> is the directory

BEGIN

END

Legenda:

Job Scheduling ConsoleJSC


2. Stop the JSC

5. Start the JSC

3. Modify the truststoreJSC

4. Modify the eystoreJSC k

Figure 4. Procedure to manage the default truststore and keystore for the Job Scheduling Console


where you installed the certificates package and the <JSC_INSTALL_DIR> is thedirectory where you installed the Job Scheduling Console.

4. Modify the keystore by copying the <PACKAGE_INSTALL_DIR>\TWS\updCertsScripts\New\PRIVATE\JSC\JSCDefaultKeyFile.jks file to the directory<JSC_INSTALL_DIR>\keys where <PACKAGE_INSTALL_DIR> is the directory whereyou installed the certificates package and <JSC_INSTALL_DIR> is the directorywhere you installed the Job Scheduling Console.

5. Start the Job Scheduling Console wizard.

Procedure to manage the default certificates for dynamicscheduling environment

To manage the default certificates for the dynamic environment, for each step inthe list, perform the procedure and then proceed with the successive step:1. Run “Procedure to manage the default truststore for dynamic agents.”2. Run “Procedure to manage the default keystore for dynamic agents” on page

32.3. If the Job Brokering Definition Console V8.5.1 is installed and works with

default certificates, run “Procedure to manage the default truststore andkeystore for the Job Brokering Definition Console” on page 36.

Note: This procedure addresses the scenario described in “Scenario: Connectionamong dynamic agents and the master domain manager or dynamic domainmanager” on page 2.

Procedure to manage the default truststore for dynamic agents


Procedure to manage the default truststore for dynamic agents

1. If the dynamic domain managers are installed, to modify the dynamic domainmanagers truststore, perform the following steps for each dynamic domainmanager:

?

Is DDM installed?

NO

BEGIN

YES

?

Is DA installed?

NO

YES

END

2. Modify the BDDM truststore

3. Modify the dynamic agent truststore

Legenda:DDM dBDDM backup dynamic domain managerDA dynamic agent

ynamic domain manager

1. Modify the DDM truststore

?

Is BDDM installed?

YES

NO

Figure 5. Procedure to manage the default truststore for dynamic agents


a. Log on as Administrator on Windows operating systems, or as root onUNIX and Linux operating systems, on the machine where the dynamicdomain manager is installed.


c. Install the package, as described in “Installing the package” on page 8.d. Stop the dynamic domain manager by running:

For dynamic domain manager V8.6.0 with related fix packs

On Windows operating systems:conman "stop"ShutdownLwa.batconman "shut;wait"stopWas.bat

On UNIX and Linux operating systems:conman "stop"ShutdownLwaconman "shut;wait"stopWas







f. Start the dynamic domain manager by running:


On Windows operating systems:conman "start"StartUpLwa.batstartWas.bat

On UNIX and Linux operating systems:conman "start"StartUpLwastartWas


For more information about the command, see User's Guide and Reference.2. If backup dynamic domain managers are installed, to modify the backup

dynamic domain managers truststore, perform the following steps for eachbackup dynamic domain manager:a. Log on as Administrator on Windows operating systems, or as root on

UNIX and Linux operating systems, on the machine where the backupdynamic domain manager is installed.



c. Install the package, as described in “Installing the package” on page 8.d. Stop the backup dynamic domain manager by running:

For backup dynamic domain manager V8.6.0 with related fix packs









f. Start the backup dynamic domain manager by running:





3. If dynamic agents are installed, to modify the dynamic agents truststore,perform the following steps for each dynamic agent:a. Log on as Administrator on Windows operating systems, or root on UNIX

and Linux operating systems, or as QSECOFR user on IBM i operatingsystems, on the machine where the dynamic agent is installed.


c. Install the package, as described in “Installing the package” on page 8.d. Stop the dynamic agent by running:

For dynamic agent V8.5.1 with related fix packs


On Windows operating systems:ShutdownLwa.bat

On UNIX and Linux operating systems:ShutdownLwa



On UNIX, Linux and IBM i operating systems:ShutdownLwa









On UNIX, Linux, and IBM i operating systems:updTrustStoresCerts.sh


f. Start the dynamic agent by running:


On Windows operating systems:StartUpLwa.bat

On UNIX and Linux operating systems:StartUpLwa



On UNIX, Linux, and IBM i operating systems:StartUpLwa


Procedure to manage the default keystore for dynamic agents


Procedure to manage the default keystore for dynamic agents

1. If dynamic agents are installed, to modify the dynamic agents keystore,perform the following steps for each dynamic agent:

?

Is DA installed?

NO

BEGIN

YES

?

NO

YES

END

2. Modify the BDDM keystore

3. Modify the DDM keystore

Legenda:DDM dBDDM backup dynamic domain managerDA dynamic agent

ynamic domain manager

1. Modify the DA keystore

?

Is BDDM installed?

?

NO

YES

?

Is DDM installed?

Figure 6. Procedure to manage the default keystore for dynamic agents


a. Log on as Administrator on Windows operating systems, as root on UNIXand Linux operating systems, or as QSECOFR user on IBM i operatingsystems, on the machine where the dynamic agent is installed.


c. Install the package, as described in “Installing the package” on page 8.d. Stop the dynamic agent by running:



On UNIX and Linux operating systems:ShutdownLwa



On UNIX, Linux, and IBM i operating systems:ShutdownLwa


e. Modify the keystore by running:






On UNIX, Linux and IBM i operating systems:updKeyStoresCerts.sh

For more information about the command syntax, see“updKeyStoreCerts” on page 12.

f. Start the dynamic agent by running:



On UNIX and Linux operating systems:StartUpLwa






2. If backup dynamic domain managers are installed, to modify the backupdynamic domain managers keystore, perform the following steps for eachbackup dynamic domain manager:a. Log on as Administrator on Windows operating systems, or as root on

UNIX and Linux operating systems, on the machine where the backupdynamic domain manager is installed.


c. Install the package, as described in “Installing the package” on page 8.d. Stop the backup dynamic domain manager by running:










f. Start the backup dynamic domain manager, by running:





3. If dynamic domain managers are installed, to modify the dynamic domainmanagers keystore, perform the following steps for each dynamic domainmanager:


a. Log on as Administrator on Windows operating systems, or as root onUNIX and Linux operating systems on the machine where the dynamicdomain manager is installed.


c. Install the package, as described in “Installing the package” on page 8.d. Stop the dynamic domain manager by running:















Procedure to manage the default truststore and keystore for theJob Brokering Definition Console


Procedure to manage the default truststore and keystore for the Job BrokeringDefinition Console


UNIX and Linux operating systems, on the machine where the JobBrokering Definition Console is installed.


c. Install the package, as described in “Installing the package” on page 8.2. Stop the Job Brokering Definition Console by closing the Job Brokering

Definition Console wizard.3. Modify the truststore by copying the <PACKAGE_INSTALL_DIR>\TWS\

updCertsScripts\New\PUBLIC\JSC\JSCDefaultTrustFile.jks file to the directory<JBDC_INSTALL_DIR>\Certs, where the <PACKAGE_INSTALL_DIR> is the directorywhere you installed the certificates package and the <JBDC_INSTALL_DIR> is thedirectory where you installed the Job Brokering Definition Console.

BEGIN

END

Legenda:

Job Brokering Definition ConsoleJBDC


2. Stop the JBDC

5. Start the JBDC

3. Modify the truststoreJBDC

4. Modify the eystoreJBDC k

Figure 7. Procedure to manage the default truststore and keystore for the Job Brokering Definition Console


4. Modify the keystore by copying the <PACKAGE_INSTALL_DIR>\TWS\updCertsScripts\New\PRIVATE\WAS\TWSClientKeyfile.jks file file (privatekey) to the directory <JBDC_INSTALL_DIR>\Certs, where <PACKAGE_INSTALL_DIR>is the directory where you installed the certificates package and<JBDC_INSTALL_DIR> is the directory where you installed the Job BrokeringDefinition Console.

5. Start the Job Brokering Definition Console wizard.

Procedure to manage the default certificates for fault-tolerantagents and domain managers in the SSL environment

To manage the default certificates for SSL environment, for each step in the list,perform the procedure and then proceed with the successive step:1. Run “Procedure to manage the default truststore for fault-tolerant agents and

domain managers.”2. Run “Procedure to manage the default keystore for fault-tolerant agents and

domain managers” on page 42.

Note: This procedure addresses the scenario described in “Scenario: SSLCommunication across the Tivoli Workload Scheduler network” on page 3.

Procedure to manage the default truststore for fault-tolerantagents and domain managers


Procedure to manage the default truststore for fault-tolerant agents and domainmanagers

1. If domain managers are installed, to modify the domain managers truststore,perform the following steps for each domain manager:

?

Is DM installed?

NO

BEGIN

YES

?

Is FTA installed?

NO

YES

END

2. Modify the BDM truststore

3. Modify the FTA truststore

Legenda:DMBDM backup domain managerFTA fault-tolerant agent

domain manager

1. Modify the DM truststore

?

Is BDM installed?

YES

NO

Figure 8. Procedure to manage the default truststore for fault-tolerant agents and domain managers


a. Log on as Administrator on Windows operating systems, or as root onUNIX and Linux operating systems, on the machine where the domainmanager is installed.


c. Install the package, as described in “Installing the package” on page 8.d. Stop the domain manager by running:

For domain manager V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with related fixpacks

On Windows, UNIX and Linux operating systems:conman "stop"conman "stopmon"conman "shut; wait"









On Windows, UNIX, and Linux operating systems:conman "start"conman "startmon"


2. If a backup domain manager is installed, to modify the backup domainmanagers truststore, perform the following steps for each backup domainmanager:a. Log on as Administrator on Windows operating systems, or as root on

UNIX and Linux operating systems, on the machine where the backupdomain manager is installed.


c. Install the package, as described in “Installing the package” on page 8.d. Stop the backup domain manager by running:

For backup domain manager V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with relatedfix packs

On Windows, UNIX, and Linux operating systems:conman "stop"conman "stopmon"conman "shut; wait"








f. Start the backup domain manager by running:




3. If fault-tolerant agents are installed, to modify the fault-tolerant agentstruststore, perform the following steps for each fault-tolerant agent:a. Log on as Administrator on Windows operating systems, or as root on



c. Install the package, as described in “Installing the package” on page 8.d. Stop the fault-tolerant agent by running:

For fault-tolerant agent V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with related fixpacks








f. Start the fault-tolerant agent by running:





Procedure to manage the default keystore for fault-tolerantagents and domain managers


Procedure to manage the default keystore for fault-tolerant agents and domainmanagers

1. If fault-tolerant agents are installed, to modify the fault-tolerant agentskeystore, perform the following steps for each fault-tolerant agent:

?

Is FTA installed?

NO

BEGIN

YES

?

NO

YES

END

2. Modify the BDM keystore

3. Modify the DM keystore

1. Modify the FTA keystore

?

Is BDM installed?

?

NO

YES

?

Is DM installed?

Legenda:DMBDM Backup Domain ManagerFTA fault-tolerant agent

Domain Manager

Figure 9. Procedure to manage the default keystore for fault-tolerant agents and domain managers


a. Log on as Administrator on Windows operating systems, or as root onUNIX and Linux operating systems, on the machine where the backupdomain manager is installed.


c. Install the package, as described in “Installing the package” on page 8.d. Stop the fault-tolerant agent by running:

For fault-tolerant agent V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with related fixpacks:








f. Start the fault-tolerant agent by running:




2. If a backup domain manager is installed, to modify the backup domainmanagers keystore, perform the following steps for each backup domainmanager:a. Log on as Administrator on Windows operating systems, or as root on



c. Install the package, as described in “Installing the package” on page 8.d. Stop the backup domain manager by running:

For backup domain manager V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with relatedfix packs:









f. Start the backup dynamic domain manager by running:




3. If domain managers are installed, to modify the domain managers keystore,perform the following steps for each domain manager:a. Log on as Administrator on Windows operating systems, or as root on

UNIX and Linux operating systems, on the machine where the domainmanager is installed.


c. Install the package, as described in “Installing the package” on page 8.d. Stop the domain manager by running:

For domain manager V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with related fixpacks:










Procedure to manage the default certificates for the connectorAPIs

Procedure to manage the default certificates for the connector APIs


UNIX and Linux operating systems, on the machine where the client fortheconnector APIs is installed.


c. Install the package, as described in “Installing the package” on page 8.

BEGIN

END

Legenda:API connector APIs


2. Find the path of the old certificates

5. Start the client

4. Re-place the truststore and keystore

3. Stop the client

Figure 10. Procedure to manage the default certificates for the connector APIs


2. Open the soap.client.props or ssl.client.props file to find the path of theTWSClientTrustFile.jks and TWSClientKeyFile.jks files.

3. Stop the client.4. Modify the certificates, if the TWSClientTrustFile.jks and

TWSClientKeyFile.jks files have not been modified, by replacing them with the<PACKAGE_INSTALL_DIR>\TWS\updCertsScripts\New\TWSClientTrustFile.jks fileand <PACKAGE_INSTALL_DIR>\TWS\DIR>\TWS\updCertsScripts\New\TWSClientKeyFile.jks, where the <PACKAGE_INSTALL_DIR> is the directorywhere you installed the certificates package.

5. Start the client.

Note: This procedure addresses the scenario described in “Scenario: Customintegration based on Tivoli Workload Scheduler Java APIs” on page 4.

Procedure to manage the default certificates for theIntegration Workbench

Procedure to manage the default certificates for the Integration Workbench


UNIX and Linux operating systems, on the machine where the IntegrationWorkbench is installed.

BEGIN

END

Legenda:SDK Integration Workbench


3. Modify the SDK keystore

2. Modify the SDK truststore

Figure 11. Procedure to manage the default certificates for the Integration Workbench



c. Install the package, as described in “Installing the package” on page 8.2. Modify truststore by copying the <PACKAGE_INSTALL_DIR>\TWS\

updCertsScripts\New\PUBLIC\WAS\TWSClientTrust.jks file to the directory<SDK_INSTALL_DIR>\keys, where the <SDK_INSTALL_DIR> is the directory whereyou installed the Integration Workbench.

3. Modify keystore by copying the <PACKAGE_INSTALL_DIR>\TWS\updCertsScripts\New\PRIVATE\WAS\TWSClientKeyfile.jks file to the directory<SDK_INSTALL_DIR>\keys, where the <SDK_INSTALL_DIR> is the directory whereyou installed the Integration Workbench.

Note: This procedure addresses the scenario described in “Scenario: IntegrationWorkbench over SSL” on page 4.

Procedure to manage the default truststore and keystore forcommand-line client

Perform the following steps:1. To modify the default certificates for the master domain manager command

lines, composer and conman, perform the “Procedure to manage the defaulttruststore and keystore for master domain manager command-line client.”

2. To modify the default certificates for the remote command-lines clients, performthe “Procedure to manage the default truststore and keystore for remotecommand-line client” on page 51.

Procedure to manage the default truststore and keystore formaster domain manager command-line client


In the master domain manager instance, you have the following localcommand-lines:v composer

v conman

Procedure to manage the default truststore and keystore for the master domainmanager command-line client

If the variable CLISSLSERVERAUTH=no in the localopts file of the masterdomain manager

You do not perform any actions because the SSL connection continues towork.

BEGIN

END


3. Copy the new certificates from the package

?

CLISSLSERVERAUTH=yesin ?localopts

NO

YES

2. Find the directoryold MDM CLIs certificates

Legenda:MDM CLIs comman-lines client in the master domain manager

Figure 12. Procedure to manage the default truststore and keystore for the master domain manager command-lineclient


If the variable CLISSLSERVERAUTH=yes in the localopts file of the masterdomain manager

1. Download and install the package by performing the following actions:a. Log on as Administrator on Windows operating systems, or as root

on UNIX and Linux operating systems, on the machine where themaster domain manager is installed.


c. Install the package, as described in “Installing the package” on page8.

2. In the localopts file of the master domain manager, note the value ofthe variable CLISSLSERVERCERTIFICATE where you store the certificatefor the master domain manager:CLISSLSERVERCERTIFICATE=<RC_CERTS_DIR>\server.crt

3. Copy the <PACKAGE_INSTALL_DIR>\TWS\updCertsScripts\New\PUBLIC\WAS\serverPublic.arm file to the directory <RC_CERTS_DIR>, where the<PACKAGE_INSTALL_DIR> is the directory where you installed thecertificates package and the <RC_CERTS_DIR> is the directory where youstore the certificate for the master domain manager.

Procedure to manage the default truststore and keystore forremote command-line client

BEGIN

END


3. Copy the new CLI certificates from the package

2. Find the directoryold CLI certificates

Legenda:CLI remote comman-line client

Figure 13. Procedure to manage the default truststore and keystore for the remote command-line client


Procedure to manage the default truststore and keystore for the remotecommand-line client

If you have remote command-lines installed for V8.3.0, V8.4.0, V8.5.0, V8.5.1.0, andV8.6.0, for each command-line, perform the following steps:1. Download and install the package by performing the following actions:

a. Log on as Administrator on Windows operating systems, or as root onUNIX and Linux operating systems, on the machine where the remotecommand-line client is installed.


c. Install the package, as described in “Installing the package” on page 8.2. In the localopts file of the remote command-line client, note the value of the

variable CLISSLSERVERCERTIFICATE where you store the certificate for the remotecommand-line client:CLISSLSERVERCERTIFICATE=<RC_CERTS_DIR>\server.crt

3. Copy the <PACKAGE_INSTALL_DIR>\TWS\updCertsScripts\New\PUBLIC\WAS\serverPublic.arm file to the directory <RC_CERTS_DIR>, where the<PACKAGE_INSTALL_DIR> is the directory where you installed the certificatespackage and the <RC_CERTS_DIR> is the directory where you store the certificatefor remote command-line client.

Procedure to manage the default keystore for master domainmanager, backup master domain manager, and agents withdistributed connector


Procedure to manage the default keystore for master domain manager, backupmaster domain manager, and agents with distributed connector

1. If a backup master domain manager is installed, to modify the keystore on thebackup master domain manager, perform the following actions:a. Log on as Administrator on Windows operating systems, or as root on

UNIX and Linux operating systems, on the machine where the backupmaster domain manager is installed.


c. Install the package, as described in “Installing the package” on page 8.d. Stop the backup master domain manager by running:

?

Is BKM installed?

NO

BEGIN

YES

?

Are agents installedwith dist connector ?

NO

YES

END

3. Modify the MDM keystore

1. Modify the BKM keystore

2. Modify the agentswith connector keystore

Legenda:MDM master domain managerBKM backup master domain manager

Figure 14. Procedure to manage the default keystore for master domain manager, backup master domain manager,and agents with distributed connector









If the backup master domain manager you installed is V8.3.0, V8.4.0,V8.5.0, V8.5.1, and V8.6.0 with related fix packs




f. Start the backup master domain manager by running:







2. Modify the keystore on the agents with distributed connector, by performingthe following steps for each type of workstation with static scheduling anddistributed connectors:


a. Log on as Administrator on Windows operating systems, or as root onUNIX and Linux operating systems, on the machine where the agent isinstalled.


c. Install the package, as described in “Installing the package” on page 8.d. Stop the agent with distributed connector by running:




If the agent with distributed connector you installed is V8.4.0, V8.5.0,V8.5.1, and V8.6.0 with related fix packs

On Windows operating systems:conman "stop"conman "stopmon"conman "shut; wait"stopWas.bat

On UNIX and Linux operating systems:conman "stop"conman "stopmon"conman "shut; wait"stopWas



If the agent with distributed connector you installed is V8.3.0, V8.4.0,V8.5.0, V8.5.1, and V8.6.0 with related fix packs




f. Start the agent with distributed connector by running:


on Windows operating systems:conman "start"startWas.cmd

on UNIX and Linux operating systems:conman "start"startWas


If the agent you installed is V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with relatedfix packs

On Windows operating systems:conman "start"conman "startmon"startWas.bat

On UNIX and Linux operating systems:conman "start"conman "startmon"startWas


3. Modify the keystore in the master domain manager by performing thefollowing actions:a. Log on as Administrator on Windows operating systems, or as root on

UNIX and Linux operating systems, on the machine where the masterdomain manager is installed.


c. Install the package, as described in “Installing the package” on page 8.d. Stop the master domain manager by running:








If the master domain manager you installed is V8.3.0, V8.4.0, V8.5.0,V8.5.1, and V8.6.0 with related fix packs





f. Start the master domain manager by running:



On UNIX and Linux operating systems:conman "start"startWas.sh


On Windows, UNIX and Linux operating systems:conman "start"conman "startmon"conman "startappserver"

For more information about the command syntax, see User's Guideand Reference.

Procedure to renew the default certificates for distributed componentsused in a z/OS environment

v If you use the default certificates in the z/OS connector for the followingscenarios perform the “Procedure to renew the default certificates for z/OSconnector on a distributed system”:– “Scenario: Connection between the Job Scheduling Console and the z/OS

connector on a distributed system” on page 5.– “Scenario: Connection between the Dynamic Workload Console and the z/OS

connector in a distributed system” on page 5.– “Scenario: Custom integration based on Tivoli Workload Scheduler Java APIs”

on page 4.– “Scenario: Integration Workbench over SSL” on page 4.

v If you use the default certificates for the “Scenario: Connection between TivoliWorkload Scheduler for z/OS agent (z-centric agent) and z/OS Controller” onpage 5, perform the “Procedure to manage the default certificates for TivoliWorkload Scheduler for z/OS agent (z-centric)” on page 69.

v If you use the default certificates for the “Scenario: Connection among dynamicdomain managers and the z/OS Controller” on page 6, perform the “Procedureto manage the default certificates for dynamic domain managers connected tothe z/OS Controller” on page 73.

Procedure to renew the default certificates for z/OS connectoron a distributed system

To modify the default certificates for scenarios described in “Scenarios fordistributed components in a z/OS environment” on page 4, follow the steps listedin Figure 15 on page 58.

You do not need to update your Tivoli Workload Scheduler environment with thefollowing procedure steps all at the same time, but you must perform the entireprocedure before the certificates expire on February 10, 2014.


Procedure to renew the default certificates for z/OS connector on a distributedsystem

LEGENDA:DWC Dynamic Workload ConsoleJSC Job Scheduling ConsoleSDK Integration Workbench

procedure default truststorefor z/OS connector

procedureconnector APIs

YES YES

NO NO NO

NO

BEGIN

END

YES

YES

YES

NO

?

Integration Workbench withdefault certificates?

?

At least one of theprevious procedures

performed?

?

DWC or JSC withdefault certificates?

procedureDWC/JSC

?


procedureSDK

procedure default keystorefor z/OS connector

?

At least one default certificatesused in the z/OS connector?

Figure 15. Procedure to renew the default certificates for z/OS connector on a distributed system


For each step in the list of procedures, if you have the described configuration,perform the procedure and then proceed with the successive step:1. If you use the default certificates in the z/OS connector, perform the

“Procedure to manage the default truststore for the z/OS connector.”2. If you use default certificates for “Scenario: Connection between the Dynamic

Workload Console and the z/OS connector in a distributed system” on page 5or “Scenario: Connection between the Job Scheduling Console and the z/OSconnector on a distributed system” on page 5 or both, perform “Procedure tomanage the default truststore and keystore for the Dynamic Workload Consoleand Job Scheduling Console” on page 23.

3. If you use the z/OS connector APIs with the default certificates, perform the“Procedure to manage the default certificates for the connector APIs” on page47.

4. If you use the Integration Workbench with the default certificates, perform the“Procedure to manage the default certificates for the Integration Workbench”on page 48.

5. If you performed any of the procedures listed in the steps 1 to 4, perform the“Procedure to manage the default keystore for the z/OS connector” on page 68.

Procedure to manage the default truststore for the z/OSconnector

Perform the following steps:1. Download and install the package by performing the following actions:

BEGIN

END


2. Stop the z/OS connector

4. Start the z/OS connector

3. Modify the z/OS connector truststore

Figure 16. Procedure to manage the default truststore for the z/OS connector


a. Log on as Administrator on Windows operating systems, or as root onUNIX and Linux operating systems, on the machine where the z/OSconnector is installed.


c. Install the package, as described in “Installing the package” on page 8.2. Stop the z/OS connector.3. Modify the truststore by running:

If the Dynamic Workload Console you installed is V8.4.0, V8.5.0, V8.5.1, andV8.6.0 with related fix packs




4. Start the z/OS connector.

Procedure to manage the default truststore and keystore for theDynamic Workload Console


Procedure to manage the default truststore and keystore for the DynamicWorkload Console


UNIX and Linux operating systems, on the machine where the DynamicWorkload Console is installed.


c. Install the package, as described in “Installing the package” on page 8.2. Stop the WebSphere Application Server of the Dynamic Workload Console by

running:

On Windows operating systems:stopWas.bat

On UNIX and Linux operating systems:stopWas.sh

BEGIN

END

Legenda:DWC Dynamic Workload Console


2. Stop the DWC

5. Start the DWC

3. Modify the DWC truststore

4. Modify the eystoreDWC k

Figure 17. Procedure to manage the default truststore and keystore for the Dynamic Workload Console






For more information about the command syntax , see “updTrustStoreCerts” onpage 9.

4. Modify the keystore by running:



For more information about the command syntax, see “updKeyStoreCerts” onpage 12.

5. Start the Dynamic Workload Console by running:

On Windows operating systems:startWas.bat

On UNIX and Linux operating systems:startWas.sh


Note for Dynamic Workload Console V8.6 or later users:

Note: For Dynamic Workload Console V8.6 or later, after you run the procedure,when you stop the WebSphere Application Server for the first time, you are askedto accept the new client truststore for the Dynamic Workload Console. Follow theprocedure “Accepting the new Dynamic Workload Console truststore when youstop the WebSphere Application Server for the first time” on page 25.

Accepting the new Dynamic Workload Console truststore when you stop theWebSphere Application Server for the first time:After you run the “Procedure to manage the default truststore and keystore for theDynamic Workload Console” on page 23, when you stop the WebSphereApplication Server for the first time, you are asked to accept the new clienttruststore for the Dynamic Workload Console.

To accept the new truststore during the running of stopWas.bat on Windowsoperating systems and stopWas.sh on UNIX and Linux operating systems, reply"y" to the prompt Add signer to the trust store now? (y/n).

On UNIX and LINUX operating systems:

If you stop the WebSphere Application Server for the first time on UNIXand Linux operating systems, by running the stopWas.sh script, you havethe following output:# ./stopWas.sh -direct -user twsuser -password twsuserADMU0116I: Tool information is being logged in file/opt/ibm/TWATDWC/eWAS/profiles/TIPProfile/logs/server1/stopServer.log


ADMU0128I: Starting tool with the TIPProfile profileADMU3100I: Reading configuration for server: server1

*** SSL SIGNER EXCHANGE PROMPT ***SSL signer from target host 9.168.125.188 is not found in trust store/opt/ibm/TWATDWC/eWAS/profiles/TIPProfile/etc/TWSClientTrustFile.jks.


Subject DN: CN=ServerNew, OU=TWS, O=IBM, C=USIssuer DN: CN=ServerNew, OU=TWS, O=IBM, C=USSerial number: 1352882899Expires: Tue Nov 09 09:48:19 CET 2032SHA-1 Digest: 5D:16:5D:17:3B:5F:BF:B7:EA:19:92:22:2D:36:53:1A:2F:9D:1B:26MD5 Digest: DB:BA:A2:6D:0D:B6:A2:53:35:6D:32:6A:40:20:D5:36Add signer to the trust store now? (y/n)yA retry of the request may need to occur if the socket times outwhile waiting for a prompt response.If the retry is required, note thatthe prompt will not be redisplayed if is entered,which indicates the signer has already been added to the trust store.ADMU3201I: Server stop request issued. Waiting for stop status.ADMU4000I: Server server1 stop completed.


If you stop the WebSphere Application Server for the first time onWindows operating systems, by running the stopWas.bat script from thewastools directory, you have the following output:C:\TWA2\wastools>stopWas.batThe service is running.Service failed to stop. stopServer return code -10

Run the stopWas.bat from the embedded WebSphere Application Serverbinary directory and you have the following output:C:\TWA2\eWAS\bin>stopServer.bat server1ADMU0116I: Tool information is being logged in fileC:\TWA2\eWAS\profiles\TIPProfile\logs\server1\stopServer.logADMU0128I: Starting tool with the TIPProfile profileADMU3100I: Reading configuration for server: server1

*** SSL SIGNER EXCHANGE PROMPT ***SSL signer from target host 9.168.125.163 is not found in trust storeC:/TWA2/eWAS/profiles/TIPProfile/etc/TWSClientTrustFile.jks.


Subject DN: CN=ServerNew, OU=TWS, O=IBM, C=USIssuer DN: CN=ServerNew, OU=TWS, O=IBM, C=USSerial number: 1352882899Expires: Mon Nov 08 20:48:19 GMT-12:00 2032SHA-1 Digest: 5D:16:5D:17:3B:5F:BF:B7:EA:19:92:22:2D:36:53:1A:2F:9D:1B:26MD5 Digest: DB:BA:A2:6D:0D:B6:A2:53:35:6D:32:6A:40:20:D5:36

Add signer to the trust store now? (y/n)yA retry of the request may need to occur if the socket times outwhile waiting for a prompt response.If the retry is required, note that the prompt will not be redisplayed if is entered,which indicates the signer has already been added to the trust store.ADMU3201I: Server stop request issued. Waiting for stop status.ADMU4000I: Server server1 stop completed.


Procedure to manage the default truststore and keystore for theJob Scheduling Console

Procedure to manage the default truststore and keystore for the Job SchedulingConsole


UNIX and Linux operating systems, on the machine where the JobScheduling Console is installed.


c. Install the package, as described in “Installing the package” on page 8.2. Stop the Job Scheduling Console by closing the wizard.3. Modify the truststore by copying the <PACKAGE_INSTALL_DIR>\TWS\

updCertsScripts\New\PUBLIC\JSC\JSCDefaultTrustFile.jks file to the directory<JSC_INSTALL_DIR>\keys where the <PACKAGE_INSTALL_DIR> is the directory

BEGIN

END

Legenda:

Job Scheduling ConsoleJSC


2. Stop the JSC

5. Start the JSC

3. Modify the truststoreJSC

4. Modify the eystoreJSC k

Figure 18. Procedure to manage the default truststore and keystore for the Job Scheduling Console


where you installed the certificates package and the <JSC_INSTALL_DIR> is thedirectory where you installed the Job Scheduling Console.

4. Modify the keystore by copying the <PACKAGE_INSTALL_DIR>\TWS\updCertsScripts\New\PRIVATE\JSC\JSCDefaultKeyFile.jks file to the directory<JSC_INSTALL_DIR>\keys where <PACKAGE_INSTALL_DIR> is the directory whereyou installed the certificates package and <JSC_INSTALL_DIR> is the directorywhere you installed the Job Scheduling Console.

5. Start the Job Scheduling Console wizard.


Procedure to manage the default certificates for the connectorAPIs

Procedure to manage the default certificates for the connector APIs


UNIX and Linux operating systems, on the machine where the client fortheconnector APIs is installed.


c. Install the package, as described in “Installing the package” on page 8.

BEGIN

END

Legenda:API connector APIs


2. Find the path of the old certificates

5. Start the client

4. Re-place the truststore and keystore

3. Stop the client

Figure 19. Procedure to manage the default certificates for the connector APIs


2. Open the soap.client.props or ssl.client.props file to find the path of theTWSClientTrustFile.jks and TWSClientKeyFile.jks files.

3. Stop the client.4. Modify the certificates, if the TWSClientTrustFile.jks and

TWSClientKeyFile.jks files have not been modified, by replacing them with the<PACKAGE_INSTALL_DIR>\TWS\updCertsScripts\New\TWSClientTrustFile.jks fileand <PACKAGE_INSTALL_DIR>\TWS\DIR>\TWS\updCertsScripts\New\TWSClientKeyFile.jks, where the <PACKAGE_INSTALL_DIR> is the directorywhere you installed the certificates package.

5. Start the client.

Note: This procedure addresses the scenario described in “Scenario: Customintegration based on Tivoli Workload Scheduler Java APIs” on page 4.

Procedure to manage the default certificates for the IntegrationWorkbench

Procedure to manage the default certificates for the Integration Workbench


UNIX and Linux operating systems, on the machine where the IntegrationWorkbench is installed.

BEGIN

END

Legenda:SDK Integration Workbench


3. Modify the SDK keystore

2. Modify the SDK truststore

Figure 20. Procedure to manage the default certificates for the Integration Workbench



c. Install the package, as described in “Installing the package” on page 8.2. Modify truststore by copying the <PACKAGE_INSTALL_DIR>\TWS\

updCertsScripts\New\PUBLIC\WAS\TWSClientTrust.jks file to the directory<SDK_INSTALL_DIR>\keys, where the <SDK_INSTALL_DIR> is the directory whereyou installed the Integration Workbench.

3. Modify keystore by copying the <PACKAGE_INSTALL_DIR>\TWS\updCertsScripts\New\PRIVATE\WAS\TWSClientKeyfile.jks file to the directory<SDK_INSTALL_DIR>\keys, where the <SDK_INSTALL_DIR> is the directory whereyou installed the Integration Workbench.

Note: This procedure addresses the scenario described in “Scenario: IntegrationWorkbench over SSL” on page 4.

Procedure to manage the default keystore for the z/OS connector

Procedure to manage the default keystore for the z/OS connector


UNIX and Linux operating systems, on the machine where the z/OSconnector is installed.

BEGIN

END


2. Stop the z/OS connector

4. Start the z/OS connector

3. Modify the z/OS connector keystore

Figure 21. Procedure to manage the default keystore for the z/OS connector



c. Install the package, as described in “Installing the package” on page 8.2. Stop the z/OS connector.3. Modify the keystore by running:

If the Dynamic Workload Console you installed is V8.4.0, V8.5.0, V8.5.1, andV8.6.0 with related fix packs




4. Start the z/OS connector.

Procedure to manage the default certificates for TivoliWorkload Scheduler for z/OS agent (z-centric)

To manage the default certificates for Tivoli Workload Scheduler for z/OS agent(z-centric), for each step in the list of procedures, perform the procedure and thenproceed with the successive step:1. Run “Procedure to manage the default truststore for Tivoli Workload Scheduler

for z/OS agent (z-centric).”2. Run “Procedure to manage the default keystore for Tivoli Workload Scheduler

for z/OS agent (z-centric)” on page 71.3. If the Job Brokering Definition Console V8.5.1 exists and works with default

certificates, run “Procedure to manage the default truststore and keystore forthe Job Brokering Definition Console” on page 36.

Note: This procedure addresses the scenario described in “Scenario: Connectionbetween Tivoli Workload Scheduler for z/OS agent (z-centric agent) and z/OSController” on page 5 only for the Tivoli Workload Scheduler for z/OS agent(z-centric). For the z/OS Controller, see the z/OS Controller documentation.

Procedure to manage the default truststore for Tivoli WorkloadScheduler for z/OS agent (z-centric)


Procedure to manage the default truststore for the Tivoli Workload Scheduler forz/OS agent (z-centric)


UNIX and Linux operating systems, on the machine where the TivoliWorkload Scheduler for z/OS agent (z-centric) is installed.


c. Install the package, as described in “Installing the package” on page 8.2. Stop the Tivoli Workload Scheduler for z/OS agent (z-centric) by running:

If the Tivoli Workload Scheduler for z/OS agent (z-centric) you installed isV8.5.1 and V8.6.0 with related fix packs





BEGIN

END


2. Stop the z-centric

4. Start the z-centric

3. Modify the z-centric truststore

Figure 22. Procedure to manage the default truststore for the Tivoli Workload Scheduler for z/OS agent (z-centric)




On UNIX, Linux and IBM i operating systems:updTrustStoresCerts.sh


4. Start the Tivoli Workload Scheduler for z/OS agent (z-centric) by running:





Procedure to manage the default keystore for Tivoli WorkloadScheduler for z/OS agent (z-centric)


Procedure to manage the default keystore for the Tivoli Workload Scheduler forz/OS agent (z-centric)


UNIX and Linux operating systems, on the machine where the TivoliWorkload Scheduler for z/OS agent (z-centric) is installed.


c. Install the package, as described in “Installing the package” on page 8.2. Stop the Tivoli Workload Scheduler for z/OS agent (z-centric) by running:





3. Modify the keystore, by running:

BEGIN

END


2. Stop the z-centric

4. Start the z-centric

3. Modify the z-centric keystore

Figure 23. Procedure to manage the default keystore for the Tivoli Workload Scheduler for z/OS agent (z-centric)




On UNIX, Linux, and IBM i operating systems:updKeyStoresCerts.sh


4. Start the Tivoli Workload Scheduler for z/OS agent (z-centric) by running:





Procedure to manage the default certificates for dynamicdomain managers connected to the z/OS Controller

To manage the default certificates for dynamic domain managers connected to thez/OS Controller, follow the procedure described in “Procedure to manage thedefault certificates for dynamic scheduling environment” on page 28.

Note: This procedure addresses the scenario described in “Scenario: Connectionamong dynamic domain managers and the z/OS Controller” on page 6. For thez/OS Controller, see the z/OS Controller documentation.


Notices

This information was developed for products and services offered in the U.S.A.IBM® may not offer the products, services, or features discussed in this documentin other countries. Consult your local IBM representative for information on theproducts and services currently available in your area. Any reference to an IBMproduct, program, or service is not intended to state or imply that only that IBMproduct, program, or service may be used. Any functionally equivalent product,program, or service that does not infringe any IBM intellectual property right maybe used instead. However, it is the user's responsibility to evaluate and verify theoperation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matterdescribed in this document. The furnishing of this document does not give youany license to these patents. You can send license inquiries, in writing, to:

IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, NY 10504-1785 U.S.A.

For license inquiries regarding double-byte (DBCS) information, contact the IBMIntellectual Property Department in your country or send inquiries, in writing, to:

Intellectual Property LicensingLegal and Intellectual Property LawIBM Japan, Ltd.19-21, Nihonbashi-Hakozakicho, Chuo-kuTokyo 103-8510, Japan

The following paragraph does not apply to the United Kingdom or any othercountry where such provisions are inconsistent with local law:

INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THISPUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHEREXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESSFOR A PARTICULAR PURPOSE.

Some states do not allow disclaimer of express or implied warranties in certaintransactions, therefore, this statement might not apply to you.

This information could include technical inaccuracies or typographical errors.Changes are periodically made to the information herein; these changes will beincorporated in new editions of the publication. IBM may make improvementsand/or changes in the product(s) and/or the program(s) described in thispublication at any time without notice.

Any references in this information to non-IBM websites are provided forconvenience only and do not in any manner serve as an endorsement of thosewebsites. The materials at those websites are not part of the materials for this IBMproduct and use of those websites is at your own risk.

75

IBM may use or distribute any of the information you supply in any way itbelieves appropriate without incurring any obligation to you.

Licensees of this program who wish to have information about it for the purposeof enabling: (i) the exchange of information between independently createdprograms and other programs (including this one) and (ii) the mutual use of theinformation which has been exchanged, should contact:

IBM Corporation2Z4A/10111400 Burnet RoadAustin, TX 78758 U.S.A.

Such information may be available, subject to appropriate terms and conditions,including in some cases payment of a fee.

The licensed program described in this document and all licensed materialavailable for it are provided by IBM under terms of the IBM Customer Agreement,IBM International Program License Agreement or any equivalent agreementbetween us.

This information contains examples of data and reports used in daily businessoperations. To illustrate them as completely as possible, the examples include thenames of individuals, companies, brands, and products. All of these names arefictitious and any similarity to the names and addresses used by an actual businessenterprise is entirely coincidental.

TrademarksIBM, the IBM logo, and ibm.com® are trademarks or registered trademarks ofInternational Business Machines Corporation in the United States, other countries,or both. If these and other IBM trademarked terms are marked on their firstoccurrence in this information with a trademark symbol (® or ™), these symbolsindicate U.S. registered or common law trademarks owned by IBM at the time thisinformation was published. Such trademarks may also be registered or commonlaw trademarks in other countries. A current list of IBM trademarks is available onthe Web at "Copyright and trademark information" at http://www.ibm.com/legal/copytrade.shtml.

Adobe, the Adobe logo, PostScript, and the PostScript logo are either registeredtrademarks or trademarks of Adobe Systems Incorporated in the United States,and/or other countries.

IT Infrastructure Library is a registered trademark of the Central Computer andTelecommunications Agency which is now part of the Office of GovernmentCommerce.

Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo,Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks orregistered trademarks of Intel Corporation or its subsidiaries in the United Statesand other countries.

Linux is a registered trademark of Linus Torvalds in the United States, othercountries, or both.


http://www.ibm.com/legal/copytrade.shtml

http://www.ibm.com/legal/copytrade.shtml

Microsoft, Windows, Windows NT, and the Windows logo are trademarks ofMicrosoft Corporation in the United States, other countries, or both.

ITIL is a registered trademark, and a registered community trademark of TheMinister for the Cabinet Office, and is registered in the U.S. Patent and TrademarkOffice

UNIX is a registered trademark of The Open Group in the United States and othercountries.

Java™ and all Java-based trademarks and logos are trademarks or registeredtrademarks of Oracle and/or its affiliates.

Cell Broadband Engine is a trademark of Sony Computer Entertainment, Inc. in theUnited States, other countries, or both and is used under license therefrom.

Linear Tape-Open, LTO, the LTO Logo, Ultrium, and the Ultrium logo aretrademarks of HP, IBM Corp. and Quantum in the U.S. and other countries.

Notices 77

Index

AAPIs

certificates 47, 66

Ccertificates

APIs 47, 66command-line client 49dynamic workload console 23, 60Integration Workbench 48, 67Job Brokering Definition Console 36Job Scheduling Console 27, 64remote command-line client 51zosconn 59

command-line clientcertificates 49

contentsPackage 8

Ddefault certificates

dynamic environment 28procedure 16, 57scripts 9SSL environment 38Tivoli Workload Scheduler for z/OS

agent 69default keystore

dynamic environment 32Tivoli Workload Scheduler for z/OS

agent (z-centric) 71distributed connector

keystore 52truststore 18

Downloadingpackage 7

dynamic environmentdefault certificates 28default keystore 32Tivoli Workload Scheduler for z/OS

agent (z-centric) 69truststore 28

dynamic workload consolecertificates 23, 60

IInstalling

package 8Integration Workbench

certificates 48, 67

JJob Brokering Definition Console

certificates 36

Job Scheduling Consolecertificates 27, 64

Kkeystore

distributed connector 52SSL environment 42zosconn 68

Ppackage

download 7installing 8

Packagecontents 8

proceduredefault certificates 16, 57

Rremote command-line client

certificates 51

SScripts

to renewdefault certificates 9

SSL environmentdefault certificates 38keystore 42TrustStore 38

TTivoli Workload Scheduler for z/OS

agentdefault certificates 69

Tivoli Workload Scheduler for z/OSagent (z-centric)

default keystore 71truststore

distributed connector 18dynamic environment 28Tivoli Workload Scheduler for z/OS

agent (z-centric) 69TrustStore

SSL environment 38

UupdKeyStoreCerts 12updTrustKeyStoreCerts 15updTrustStoreCerts 9

Zzosconn

certificates 59keystore 68

79

��

Product Number: 5698-WSH

Printed in USA

renewing default certificates for tivoli workload scheduler

Documents

default truststore andkeystore

distributed connector

dynamicworkload console

zos controller6chapter

backup master domainmanager

dynamic domainmanagers

zos agentzcentric69procedure

tivoli workloadscheduler