Renewing Default Certificates For Tivoli Workload Scheduler

IBM Tivoli Workload Scheduler
Renewing default certificates for Tivoli Workload Scheduler

V ersion 8.3.0 8. 4.0 8.5.0 8.5.1 8.6.0
IBM Tivoli Workload Scheduler
Renewing default certificates for Tivoli Workload Scheduler

V ersion 8.3.0 8. 4.0 8.5.0 8.5.1 8.6.0
Note Before using this information and the product it supports, read the information in Notices on page 75.
Contents
Chapter 1. Scenarios affected by default certificates expiration . . . . . . . . . 1
Scenarios for the distributed environment . . . Scenario: Connection between the Dynamic Workload Console and agent with a distributed connector . . . . . . . . . . . . . Scenario: Connection between the Job Scheduling Console and agent with a distributed connector Scenario: Connection among dynamic agents and the master domain manager or dynamic domain manager . . . . . . . . . . . . . . Scenario: SSL Communication across the Tivoli Workload Scheduler network . . . . . . . Scenario: Custom integration based on Tivoli Workload Scheduler Java APIs . . . . . . Scenario: Integration Workbench over SSL . . Scenario: HTTPS for the command-line clients . Scenarios for distributed components in a z/OS environment . . . . . . . . . . . . . Scenario: Connection between the Dynamic Workload Console and the z/OS connector in a distributed system . . . . . . . . . . Scenario: Connection between the Job Scheduling Console and the z/OS connector on a distributed system . . . . . . . . . . . . . . Scenario: Connection between Tivoli Workload Scheduler for z/OS agent (z-centric agent) and z/OS Controller . . . . . . . . . . . Scenario: Connection among dynamic domain managers and the z/OS Controller . . . . . . 1 updTrustKeyStoreCerts . . . . . . . . . Procedure to renew the default certificates in a distributed environment . . . . . . . . . . Procedure to manage the default truststore for master domain manager, backup master domain manager, and agents with distributed connector . Procedure to manage the default truststore and keystore for the Dynamic Workload Console and Job Scheduling Console . . . . . . . . . Procedure to manage the default certificates for dynamic scheduling environment . . . . . . Procedure to manage the default certificates for fault-tolerant agents and domain managers in the SSL environment . . . . . . . . . . . Procedure to manage the default certificates for the connector APIs . . . . . . . . . . . Procedure to manage the default certificates for the Integration Workbench . . . . . . . . Procedure to manage the default truststore and keystore for command-line client . . . . . . Procedure to manage the default keystore for master domain manager, backup master domain manager, and agents with distributed connector . Procedure to renew the default certificates for distributed components used in a z/OS environment . . . . . . . . . . . . . . Procedure to renew the default certificates for z/OS connector on a distributed system . . . . Procedure to manage the default certificates for Tivoli Workload Scheduler for z/OS agent (z-centric) . . . . . . . . . . . . . . Procedure to manage the default certificates for dynamic domain managers connected to the z/OS Controller . . . . . . . . . . . . 15 16
. 2 . 2
18
23 28
. 2 . 3 . 4 . 4 . 4 . 4
38 47 48 49
. 5
52
. 5
57 57
. 5 . 6
69
Chapter 2. How to renew the default certificates . . . . . . . . . . . . . 7

Downloading the package . Installing the package . . Package contents . . . Scripts to renew the default updTrustStoreCerts . . updKeyStoreCerts . . . . . . . . . . . 7 . . . . . . . . . 8 . . . . . . . . . 8 certificates . . . . . 9 . . . . . . . . . 9 . . . . . . . . . 12
73
Notices . . . . . . . . . . . . . . 75
Trademarks . . . . . . . . . . . . . . 76
Index . . . . . . . . . . . . . . . 79
iii
iv
Renewing default certificates
Chapter 1. Scenarios affected by default certificates expiration

Tivoli Workload Scheduler provides a secure, authenticated, and encrypted connection 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 SSL protocol that is based on a private and public key methodology. The following terminology is used: truststore In security, a storage object, either a file or a hardware cryptographic card, where public keys are stored in the form of trusted certificates, for authentication purposes in web transactions. In some applications, these trusted certificates are moved into the application keystore to be stored with the private keys. keystore In security, a file or a hardware cryptographic card where identities and private keys are stored, for authentication and encryption purposes. Some keystores also contain trusted or public keys. If you do not customize SSL communication with your own certificates, Tivoli Workload Scheduler uses the default certificates that are stored in the default directories 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, the administrator must renew the default certificates for the following scenarios because 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 these scenarios. For more information about how to do this, see Chapter 2, How to renew the default certificates, on page 7.
Scenarios for the distributed environment

The following scenarios for the distributed environment are affected by the expiration date: v Scenario: Connection between the Dynamic Workload Console and agent with a distributed connector on page 2 v Scenario: Connection between the Job Scheduling Console and agent with a distributed connector on page 2 v Scenario: Connection among dynamic agents and the master domain manager or dynamic domain manager on page 2 v Scenario: SSL Communication across the Tivoli Workload Scheduler network on page 3
v Scenario: Custom integration based on Tivoli Workload Scheduler Java APIs on page 4 v Scenario: Integration Workbench over SSL on page 4 v Scenario: HTTPS for the command-line clients on page 4 Your environment might include one or more of these scenarios. For more information about how to update the default certificates in the correct order for these scenarios, see Procedure to renew the default certificates in a distributed environment on page 16.
Scenario: Connection between the Dynamic Workload Console and agent with a distributed connector
The SSL communication between the Dynamic Workload Console and one of the following types of Tivoli Workload Scheduler component is affected by the expiration 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 Console and on the distributed connector installed on the agent before the expiration date, the communication between the user interface and the connector is broken. In the Tivoli Workload Scheduler distributed environment, you can manage the Tivoli Workload Scheduler database objects and plan objects using the composer and conman commands.
Scenario: Connection between the Job Scheduling Console and agent with a distributed connector
The SSL communication between the Job Scheduling Console and one of the following types of Tivoli Workload Scheduler component is affected by the expiration 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 on the distributed connector installed on the agent before the expiration date, the communication between the user interface and the connector is broken. In the Tivoli Workload Scheduler distributed environment, you can manage the Tivoli Workload Scheduler database objects and plan objects using the composer and conman commands.
Scenario: Connection among dynamic agents and the master domain 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.
v Dynamic domain manager and backup dynamic domain manager. The SSL communication between the Broker Server installed on the master domain manager and one of the following components is affected by the expiration date of the 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 the dynamic domain manager and on the dynamic agents before the expiration date, the communication between the dynamic domain manager and the dynamic agents is broken. The communication between the ResourceCLI command line installed on the dynamic domain manager and the Broker Server installed on the master domain manager is also broken. Note: v The dynamic domain manager and backup dynamic domain manager components are included in V8.6.0 and later. v On Windows, UNIX, and Linux operating systems, the dynamic agent component is included in V8.5.1 and later. On IBM i operating systems, the dynamic agent component is included in V8.6.0.
Scenario: SSL Communication across the Tivoli Workload Scheduler network

You can enable the SSL connection using OpenSSL Toolkit for the following components: v v v v Master domain manager and its domain managers Master domain manager and fault-tolerant agents in the master domain Master domain manager and backup master domain manager 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 related fix packs in the network is affected by the expiration date of the default certificates. If the version of the Tivoli Workload Scheduler instance is V8.4.0 or an upgrade of V8.4.0 and related fix packs, the default certificates are located in the <INSTALL_DIR>\TWS\ssl\sslDefault directory; in other cases the default certificates are located in the <INSTALL_DIR>\TWS\ssl\OpenSSL directory. All Tivoli Workload Scheduler administrators who use the OpenSSL default certificates for SSL communication must modify the certificates to maintain a working SSL environment.
Note: The default GSKit certificates expiration date is not the "February 10, 2014" and administrators are not required to perform any recovery actions. Check periodically the GSKit certificates expiration date to keep the default certificates up-to-date.
Scenario: Custom integration based on Tivoli Workload Scheduler Java APIs

If you have an SSL connection that uses default certificates in a custom integration based on Tivoli Workload Scheduler Java APIs V8.3.0, V8.4.0, V8.5.0, V8.5.1, or V8.6.0 with related fix packs, the communication does not work after the default certificates expiration date.
Scenario: Integration Workbench over SSL

Integration Workbench is used to develop custom plug-ins. If you have an SSL connection that uses default certificates for the Integration Workbench V8.4.0, V8.5.0, V8.5.1, or V8.6.0 with related fix packs, the communication does not work after the default certificates expiration date.
Scenario: HTTPS for the command-line clients

You 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 manager and the connector: The variable CLISSLSERVERAUTH=no in the master domain manager localopts file The communication continues to work after the default certificates expiration date. The variable CLISSLSERVERAUTH=yes in the master domain manager localopts file The communication does not work after the default certificates expiration date. v If you have an SSL connection that uses default certificates between the remote command-line client and the master domain manager: The variable CLISSLSERVERAUTH=no in the remote command-line client localopts file The communication continues to work after the default certificates expiration date. The variable CLISSLSERVERAUTH=yes in the remote command-line client localopts file The communication does not work after the default certificates expiration date.
Scenarios for distributed components in a z/OS environment

The following scenarios for distributed components in a z/OS environment are affected 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 4 v 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. To update default certificates in the correct order for these scenarios, see Procedure to renew the default certificates for distributed components used in a z/OS environment on page 57.
Scenario: Connection between the Dynamic Workload Console and the z/OS connector in a distributed system
The SSL communication between the Dynamic Workload Console and the z/OS connector installed in a distributed system is affected by the expiration date of the default certificates. If you do not modify the default certificates on the Dynamic Workload Console and the z/OS connector before the expiration date, the communication between the user interface and the connector is broken. In a Tivoli Workload Scheduler z/OS environment, you can manage the database objects and plan objects by using ISPF panels.
Scenario: Connection between the Job Scheduling Console and the z/OS connector on a distributed system
The SSL communication between the Job Scheduling Console and the z/OS connector installed in a distributed system is affected by the expiration date of the default certificates. If you do not modify the default certificates on the Job Scheduling Console and the z/OS connector before the expiration date, the communication between the user interface and the connector is broken. In a Tivoli Workload Scheduler z/OS environment, you can manage the database objects and plan objects by using ISPF panels.
Scenario: Connection between Tivoli Workload Scheduler for z/OS agent (z-centric agent) and z/OS Controller
The SSL communication between the z/OS Controller and the z-centric agent 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 the z-centric agent before the expiration date, the communication between the z/OS Controller and the z-centric agent is broken. Note: On Windows, UNIX, and Linux operating systems, the z-centric agent component is included in V8.5.1 and later. On IBM i operating systems, the z-centric agent component is included in V8.6.0.
Scenario: Connection among dynamic domain managers and the z/OS Controller
The SSL communication between the z/OS Controller and the dynamic domain managers 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 the dynamic domain managers before the expiration date, the communication between the z/OS Controller and the dynamic domain managers is broken. Note: The dynamic domain manager and backup dynamic domain manager components 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 default certificates and a set of scripts that you use to modify the old default certificates with the new ones, for each of the following versions at each level of fix pack: v V8.3.0 v v v v V8.4.0 V8.5.0 V8.5.1 V8.6.0
For more information about how to download the package for the version you need to install, see Downloading the package.
Downloading the package

To 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.0 8.3.0-TIV-TWA-CERTIFICATES Tivoli Workload Scheduler component V8.4.0 8.4.0-TIV-TWA-CERTIFICATES Tivoli Workload Scheduler component V8.5.0 8.5.0-TIV-TWA-CERTIFICATES Tivoli Workload Scheduler component V8.5.1 8.5.1-TIV-TWA-CERTIFICATES Tivoli Workload Scheduler component V8.6.0 8.6.0-TIV-TWA-CERTIFICATES 5. Download the package you selected into the <PACKAGE_INSTALL_DIR> generic directory. The package contains the following .zip file: Package V8.3.0 updCertsScripts_v830.zip Package V8.4.0 updCertsScripts_v840.zip Package V8.5.0 updCertsScripts_v850.zip
Package V8.5.1 updCertsScripts_v851.zip Package V8.6.0 updCertsScripts_v860.zip
Installing the package

After you downloaded the package into the generic <PACKAGE_INSTALL_DIR> directory, as described in Downloading the package on page 7, to install the package, 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 the Tivoli Workload Scheduler component installed where you need to manage the default certificates. 2. On UNIX operating systems, to give the correct read and write access to all files 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 contents
If you installed the package as described in Installing the package, you have the contents 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>
where v <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 certificates v Old directory that contains old defaults certificates v 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 certificates

The package provides a set of scripts that you use to manage and update the Tivoli Workload Scheduler truststore and Tivoli Workload Scheduler keystore related to the default certificates: v updTrustStoreCerts. v updKeyStoreCerts on page 12. v updTrustKeyStoreCerts on page 15.
updTrustStoreCerts
The updTrustStoreCerts script checks the truststore in the default SSL location for the 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 the old truststore and the new truststore. After modifying the truststore, if you do not immediately update the keystore for the default certificates, all the communication scenarios described in Chapter 1, Scenarios affected by default certificates expiration, on page 1, continue to work until the expiration date. If you store your own truststore in the SSL default directory, the installation process does not modify the truststore contents. The installation process checks if the checksum of the certificate is the checksum of the default certificate released at general 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 are running. v Run the script as Administrator on Windows operating systems, root on UNIX and 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 instance of 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
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 where <PROFILENAME> is: v twsprofile for master domain manager or backup master domain manager. v twsconnprofile for distributed connector. 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\OpenSSL\TWSTrustCertificates.cer 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\OpenSSL\TWSTrustCertificates.cer v <INSTALL_DIR>\TWS\ssl\sslDefault\ TWSCertificateChainFile.pem (if the Tivoli Workload Scheduler is 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 Common Name value in the default truststore certificate that is ServerNew. On UNIX operating systems: The script syntax is:
./updTrustStoresCerts.sh <INSTALL_DIR>
where <INSTALL_DIR> is the installation directory of the selected instance of Tivoli Workload Scheduler.
10
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 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 where <PROFILENAME> is: v twsprofile for master domain manager or backup master domain manager. v twsconnprofile for distributed connector. 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/OpenSSL/TWSTrustCertificates.cer 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/OpenSSL/TWSTrustCertificates.cer
11
v <INSTALL_DIR>/TWS/ssl/sslDefault/ TWSCertificateChainFile.pem (if the Tivoli Workload Scheduler is 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 Common Name value in the default truststore certificate which is ServerNew. On IBM i operating systems: The script syntax is:
./updTrustStoresCerts.sh <INSTALL_DIR>
where <INSTALL_DIR> is the installation directory of the selected instance of Tivoli Workload Scheduler. The script installs the following new file: V8.3.0, V8.4.0, V8.5.0, and V8.5.1 Not 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
updKeyStoreCerts
The updKeyStoreCerts script checks the keystore in the default SSL location for the current instance of Tivoli Workload Scheduler. If the default keystore is used, the script backs up the old keystore contents and adds the new keystore contents. The script saves the old certificates with a .bck extension. Note: v Run the script only when no Tivoli Workload Scheduler instance processes are running. v Run the script as Administrator on Windows operating systems, root on UNIX and Linux operating systems, and QSECOFR user on IBM i operating systems. On Windows operating systems: The script syntax is:
updateKeyStoresCerts.bat "<INSTALL_DIR>"
where <INSTALL_DIR> is the installation directory of the selected instance of Tivoli Workload Scheduler. The script installs the following new files: V8.3.0 v <INSTALL_DIR>\AppServer\profiles\<PROFILENAME>\etc\ TWSServerKeyFile.jks v <INSTALL_DIR>\AppServer\profiles\<PROFILENAME>\etc\ TWSClientKeyFile.jks
12
where <PROFILENAME> is: v twsprofile for master domain manager or backup master domain manager. v twsconnprofile for distributed connector. 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 where <PROFILENAME> is: v twsprofile for master domain manager or backup master domain manager. v twsconnprofile for distributed connector. 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 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.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 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
13
On UNIX and Linux operating systems: The script syntax is:

./updKeyStoresCerts.sh <INSTALL_DIR>
where <INSTALL_DIR> is the installation directory of the selected instance of Tivoli Workload Scheduler. The script installs the following new files: V8.3.0 v <INSTALL_DIR>/AppServer/profiles/<PROFILENAME>/etc/ TWSServerKeyFile.jks v <INSTALL_DIR>/AppServer/profiles/<PROFILENAME>/etc/ TWSClientKeyFile.jks where <PROFILENAME> is: v twsprofile for master domain manager or backup master domain manager. v twsconnprofile for distributed connector. 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 where <PROFILENAME> is: v twsprofile for master domain manager or backup master domain manager. v twsconnprofile for distributed connector. 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 v v v v <INSTALL_DIR>/TDWB_CLI/certs/TWSClientKeyFile.jks <INSTALL_DIR>/TWS/ITA/TWSClientKeyStore.kdb <INSTALL_DIR>/TWS/ssl/OpenSSL/TWSClient.key <INSTALL_DIR>/TWS/ssl/OpenSSL/TWSClient.cer <INSTALL_DIR>/TWS/ssl/sslDefault/TWSPrivateKeyFile.pem
14
v <INSTALL_DIR>/TWS/ssl/sslDefault/TWSPublicKeyFile.pem 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 v v v v <INSTALL_DIR>/TWS/ssl/OpenSSL/TWSClient.key <INSTALL_DIR>/TWS/ssl/OpenSSL/TWSClient.cer <INSTALL_DIR>/TWS/ssl/sslDefault/TWSPrivateKeyFile.pem <INSTALL_DIR>/TWS/ssl/sslDefault/TWSPublicKeyFile.pem
On IBM i operating systems: The script syntax is:

where <INSTALL_DIR> is the installation directory of the selected instance of Tivoli Workload Scheduler. The script installs the following new files: V8.3.0, V8.4.0, V8.5.0, and V8.5.1 Not 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 If you installed Tivoli Workload Scheduler V8.6.0 in the default directory, you run: On Windows operating systems:
updateKeyStoresCerts.bat "C:\Program Files\IBM\TWA"

./updateKeyStoresCerts.sh /opt/IBM/TWA
updTrustKeyStoreCerts
The updTrustKeyStoreCerts script runs first the updTrustStoresCerts and then the updKeyStoresCerts scripts to update the truststore and the keystore. The script saves the old certificates with a .bck extension. Note: v Run the script only when no Tivoli Workload Scheduler instance processes are running. v Run the script as Administrator on Windows operating systems, root on UNIX and Linux operating systems, and QSECOFR user on IBM i operating systems. On Windows operating systems: The script syntax is:
updateTrustKeyStoresCerts.bat "<INSTALL_DIR>"
15
where <INSTALL_DIR> is the installation directory of the selected instance of Tivoli Workload Automation. For a list of the files affected by this script, see the list for the updTrustStoresCerts and the updKeyStoresCerts scripts. On UNIX and Linux operating systems: The script syntax is:
where <INSTALL_DIR> is the installation directory of the selected instance of Tivoli Workload Automation. For a list of the files affected by this script, see the list for the updTrustStoresCerts and the updKeyStoresCerts scripts. On IBM i operating systems: The script syntax is:
./updTrustKeyStoresCerts.sh <INSTALL_DIR>
where <INSTALL_DIR> is the installation directory of the selected instance of Tivoli Workload Automation. For a list of the files affected by this script, see the list for the updTrustStoresCerts and the updKeyStoresCerts scripts. If you installed Tivoli Workload Scheduler V8.6.0 in the default directory, you run: On Windows operating systems:
updateTrustKeyStoresCerts.bat "C:\Program Files\IBM\TWA"

./updateTrustKeyStoresCerts.sh /opt/IBM/TWA
Procedure to renew the default certificates in a distributed environment

To modify the default certificates for the scenarios described in Scenarios for the distributed 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 the following procedure steps all at the same time, but you must perform the entire procedure before the certificates expire on February 10, 2014.
16
BEGIN
NO
at least one default certificate used in the MDM?

YES
procedure default truststore for MDM, BKM, agents with dist connector
? NO
? NO
DWC or JSC with default certificates?
Dynamic environment with default certificates?
SSL across network with default certificates?
NO
YES
YES
YES
procedure DWC/JSC
procedure Dynamic environment
procedure SSL network
NO
NO
NO
connector APIs with default certificates?

YES
Integration Workbench with default certificates?

YES
CLIs with default certificates?

YES
procedure connector APIs
procedure sdk
procedure CLIs
At least one of the previous procedures performed?

YES
NO
procedure default keystore for MDM, BKM, agents with dist connector
END
LEGENDA: MDM master domain manager BKM backup master domain manager DWC Dynamic Workload Console JSC Job Scheduling Console CLI command-line client
Figure 1. Procedure to renew the default certificates in a distributed environment
Procedure to renew the default certificates in a distributed environment
17
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 Console configured over SSL with the default certificates, perform the Procedure to manage the default truststore and keystore for the Dynamic Workload Console and Job Scheduling Console on page 23. 3. If you have the dynamic environment configured in SSL with the default certificates, perform theProcedure to manage the default certificates for dynamic scheduling environment on page 28. 4. If you have the SSL communication enabled in Tivoli Workload Scheduler environment with OpenSSL default certificates, perform the Procedure to manage the default certificates for fault-tolerant agents and domain managers in 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 page 47. 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-line client 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, backup master domain manager, and agents with distributed connector on page 52.
Procedure to manage the default truststore for master domain manager, backup master domain manager, and agents with distributed connector
18
BEGIN
1. Modify the MDM truststore
? NO
Is BKM installed?
YES
2. Modify the BKM truststore
Are agents installed with dist connector ?

YES
NO
3. Modify the agents with connector truststore
END
Legenda: MDM master domain manager BKM 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
Procedure to manage the default truststore for master domain manager, backup master domain manager, and agents with distributed connector 1. To modify the master domain 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 master domain manager is installed.
19
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 fix packs 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, and V8.6.0 with related fix packs On Windows, UNIX, and Linux operating systems:
conman conman conman conman "stop" "stopmon" "stopappserver" "shut; wait"
For more information about the command syntax, see User's Guide and Reference. 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.0 with related fix packs: On Windows operating systems:
updTrustStoresCerts.bat

updTrustStoresCerts.sh
For more information about the command syntax, see updTrustStoreCerts on page 9. f. Start the master domain manager by running: If the master domain manager you installed is V8.3.0 with related fix packs On Windows operating systems:
conman "start" startWas.cmd

conman "start" startWas.sh
conman "start" conman "startmon" conman "startappserver"
20
For more information about the command syntax, see User's Guide and Reference. 2. If the backup master domain manager is installed, to modify the backup master domain 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 backup master domain manager is installed. 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 backup master domain manager by running: If the backup master domain manager you installed is V8.3.0 with related fix packs On Windows operating systems:

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:
For more information about the command syntax, see User's Guide and Reference. e. Modify the truststore by running: For backup master domain manager V8.3.0, V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with related fix packs On Windows operating systems:

For more information about the command syntax, see updTrustStoreCerts on page 9. f. Start the backup master domain manager by running: If the backup master domain manager you installed is V8.3.0 with related fix packs On Windows operating systems:

conman "start" startWas
21
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 Windows, UNIX, and Linux operating systems:
3. Modify the truststore for the agents with distributed connector by performing the following steps for each type of workstation with static scheduling and distributed 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 is installed. 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 agent with distributed connector by running: If the agent with distributed connector you installed is V8.3.0 with related fix packs On Windows operating systems:

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

conman "stop" conman "stopmon" conman "shut; wait" stopWas
For more information about the command syntax, see User's Guide and Reference. e. Modify the truststore by running: For agent with distributed connector V8.3.0, V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with related fix packs On Windows operating systems:

For more information about the command syntax, see updTrustStoreCerts on page 9. f. Start the agent with distributed connector by running:
22
If the agent with distributed connector you installed is V8.3.0 with related fix packs On Windows operating systems:

If the agent 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 "start" conman "startmon" startWas.bat

conman "start" conman "startmon" startWas
For more information about the command syntax, see User's Guide and Reference.
Procedure to manage the default truststore and keystore for the 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 Dynamic Workload Console and agent with a distributed connector on page 2, run Procedure to manage the default truststore and keystore for the Dynamic Workload Console. 2. If the Job Scheduling Console is installed and works with default certificates as described in Scenario: Connection between the Job Scheduling Console and agent with a distributed connector on page 2, run Procedure to manage the default truststore and keystore for the Job Scheduling Console on page 27.
Procedure to manage the default truststore and keystore for the Dynamic Workload Console
23
BEGIN
1. Download and install the package
2. Stop the DWC
3. Modify the DWC truststore
4. Modify the DWC keystore
5. Start the DWC
END
Legenda: DWC Dynamic Workload Console

Figure 3. Procedure to manage the default truststore and keystore for the Dynamic Workload Console
Procedure to manage the default truststore and keystore for the Dynamic Workload 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 Dynamic Workload Console is installed. 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. 2. Stop the WebSphere Application Server of the Dynamic Workload Console by running: On Windows operating systems:
stopWas.bat

stopWas.sh
24
For more information about the command syntax, see Tivoli Workload Scheduler: Administration Guide > Administrative tasks > Application Server tasks. 3. Modify the truststore by running: On Windows operating systems:

For more information about the command syntax , see updTrustStoreCerts on page 9. 4. Modify the keystore by running: On Windows operating systems:
updKeyStoresCerts.bat

updKeyStoresCerts.sh
For more information about the command syntax, see updKeyStoreCerts on page 12. 5. Start the Dynamic Workload Console by running: On Windows operating systems:
startWas.bat

startWas.sh
For more information about the command syntax, see Tivoli Workload Scheduler: Administration Guide > Administrative tasks > Application Server tasks. 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 asked to accept the new client truststore for the Dynamic Workload Console. Follow the procedure Accepting the new Dynamic Workload Console truststore when you stop the WebSphere Application Server for the first time. Accepting the new Dynamic Workload Console truststore when you stop the WebSphere Application Server for the first time: After you run the Procedure to manage the default truststore and keystore for the Dynamic Workload Console on page 23, when you stop the WebSphere Application Server for the first time, you are asked to accept the new client truststore for the Dynamic Workload Console. To accept the new truststore during the running of stopWas.bat on Windows operating 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 UNIX and Linux operating systems, by running the stopWas.sh script, you have the following output:
# ./stopWas.sh -direct -user twsuser -password twsuser ADMU0116I: Tool information is being logged in file /opt/ibm/TWATDWC/eWAS/profiles/TIPProfile/logs/server1/stopServer.log
25
ADMU0128I: Starting tool with the TIPProfile profile ADMU3100I: 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=US Issuer DN: CN=ServerNew, OU=TWS, O=IBM, C=US Serial number: 1352882899 Expires: Tue Nov 09 09:48:19 CET 2032 SHA-1 Digest: 5D:16:5D:17:3B:5F:BF:B7:EA:19:92:22:2D:36:53:1A:2F:9D:1B:26 MD5 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)y A retry of the request may need to occur if the socket times out while 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.
On Windows operating systems: If you stop the WebSphere Application Server for the first time on Windows operating systems, by running the stopWas.bat script from the wastools directory, you have the following output:
C:\TWA2\wastools>stopWas.bat The service is running. Service failed to stop. stopServer return code -10
Run the stopWas.bat from the embedded WebSphere Application Server binary directory and you have the following output:
C:\TWA2\eWAS\bin>stopServer.bat server1 ADMU0116I: Tool information is being logged in file C:\TWA2\eWAS\profiles\TIPProfile\logs\server1\stopServer.log ADMU0128I: Starting tool with the TIPProfile profile ADMU3100I: Reading configuration for server: server1 *** SSL SIGNER EXCHANGE PROMPT *** SSL signer from target host 9.168.125.163 is not found in trust store C:/TWA2/eWAS/profiles/TIPProfile/etc/TWSClientTrustFile.jks. Here is the signer information (verify the digest value matches what is displayed at the server): Subject DN: Issuer DN: Serial number: Expires: SHA-1 Digest: MD5 Digest: CN=ServerNew, OU=TWS, O=IBM, C=US CN=ServerNew, OU=TWS, O=IBM, C=US 1352882899 Mon Nov 08 20:48:19 GMT-12:00 2032 5D:16:5D:17:3B:5F:BF:B7:EA:19:92:22:2D:36:53:1A:2F:9D:1B:26 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)y A retry of the request may need to occur if the socket times out while 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 add ed to the trust store. ADMU3201I: Server stop request issued. Waiting for stop status. ADMU4000I: Server server1 stop completed.
26
Procedure to manage the default truststore and keystore for the Job Scheduling Console
BEGIN
2. Stop the JSC
3. Modify the JSC truststore
4. Modify the JSC keystore
5. Start the JSC
END
Legenda: JSC Job Scheduling Console

Figure 4. Procedure to manage the default truststore and keystore for the Job Scheduling Console
Procedure to manage the default truststore and keystore for the Job Scheduling 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 Job Scheduling Console is installed. 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. 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
27
where you installed the certificates package and the <JSC_INSTALL_DIR> is the directory 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 where you installed the certificates package and <JSC_INSTALL_DIR> is the directory where you installed the Job Scheduling Console. 5. Start the Job Scheduling Console wizard.
Procedure to manage the default certificates for dynamic scheduling environment

To manage the default certificates for the dynamic 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 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 and keystore for the Job Brokering Definition Console on page 36. Note: This procedure addresses the scenario described in Scenario: Connection among dynamic agents and the master domain manager or dynamic domain manager on page 2.
Procedure to manage the default truststore for dynamic agents
28
BEGIN
NO
Is DDM installed?
YES
1. Modify the DDM truststore
NO
Is BDDM installed?
? YES
2. Modify the BDDM truststore
NO
Is DA installed?
YES
3. Modify the dynamic agent truststore
END
Legenda: DDM dynamic domain manager BDDM backup dynamic domain manager DA dynamic agent
Figure 5. 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 domain managers truststore, perform the following steps for each dynamic domain manager:
29
a. Log on as Administrator on Windows operating systems, or as root on UNIX and Linux operating systems, on the machine where the dynamic domain manager is installed. 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 dynamic domain manager by running: For dynamic domain manager V8.6.0 with related fix packs On Windows operating systems:
conman "stop" ShutdownLwa.bat conman "shut;wait" stopWas.bat

conman "stop" ShutdownLwa conman "shut;wait" stopWas
For more information about the command syntax, see User's Guide and Reference. e. Modify the truststore by running: For dynamic domain manager V8.6.0 with related fix packs On Windows operating systems:

For more information about the command syntax, see updTrustStoreCerts on page 9. f. Start the dynamic domain manager by running: For dynamic domain manager V8.6.0 with related fix packs On Windows operating systems:
conman "start" StartUpLwa.bat startWas.bat

conman "start" StartUpLwa startWas
For more information about the command syntax, see User's Guide and Reference. 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 each backup 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 backup dynamic domain manager is installed.
30
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 backup dynamic domain manager by running: For backup dynamic domain manager V8.6.0 with related fix packs On Windows operating systems:

For more information about the command syntax, see User's Guide and Reference. e. Modify the truststore by running: For backup dynamic domain manager V8.6.0 with related fix packs On Windows operating systems:

For more information about the command syntax, see updTrustStoreCerts on page 9. f. Start the backup dynamic domain manager by running: For backup dynamic domain manager V8.6.0 with related fix packs On Windows operating systems:

For more information about the command syntax, see User's Guide and Reference. 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 operating systems, on the machine where the dynamic agent is installed. 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 dynamic agent by running: For dynamic agent V8.5.1 with related fix packs
31
On Windows operating systems:

ShutdownLwa.bat

ShutdownLwa
For dynamic agent V8.6.0 with related fix packs On Windows operating systems:
ShutdownLwa.bat
On UNIX, Linux and IBM i operating systems:

ShutdownLwa
For more information about the command syntax, see User's Guide and Reference. e. Modify the truststore by running: For dynamic agent V8.5.1 with related fix packs On Windows operating systems:

For more information about the command syntax, see updTrustStoreCerts on page 9. For dynamic agent V8.6.0 with related fix packs On Windows operating systems:

For more information about the command syntax, see updTrustStoreCerts on page 9. f. Start the dynamic agent by running: For dynamic agent V8.5.1 with related fix packs On Windows operating systems:
StartUpLwa.bat

StartUpLwa
StartUpLwa.bat

StartUpLwa
Procedure to manage the default keystore for dynamic agents
32
BEGIN
NO
Is DA installed?
YES
1. Modify the DA keystore
NO
Is BDDM installed?
? YES
2. Modify the BDDM keystore
NO
Is DDM installed?
? YES
3. Modify the DDM keystore
END
Legenda: DDM dynamic domain manager BDDM backup dynamic domain manager DA dynamic agent
Figure 6. 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:
33
a. Log on as Administrator on Windows operating systems, as root on UNIX and Linux operating systems, or as QSECOFR user on IBM i operating systems, on the machine where the dynamic agent is installed. 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 dynamic agent by running: For dynamic agent V8.5.1 with related fix packs On Windows operating systems:
ShutdownLwa.bat

ShutdownLwa
ShutdownLwa.bat

ShutdownLwa
For more information about the command syntax, see User's Guide and Reference. e. Modify the keystore by running: For dynamic agent V8.5.1 with related fix packs On Windows operating systems:


For more information about the command syntax, see updKeyStoreCerts on page 12. f. Start the dynamic agent by running: For dynamic agent V8.5.1 with related fix packs On Windows operating systems:
StartUpLwa.bat

StartUpLwa
StartUpLwa.bat

StartUpLwa
34
For more information about the command syntax, see User's Guide and Reference. 2. If backup dynamic domain managers are installed, to modify the backup dynamic domain managers keystore, perform the following steps for each backup 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 backup dynamic domain manager is installed. 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 backup dynamic domain manager by running: For backup dynamic domain manager V8.6.0 with related fix packs On Windows operating systems:

For more information about the command syntax, see User's Guide and Reference. e. Modify the keystore by running: For backup dynamic domain manager V8.6.0 with related fix packs On Windows operating systems:

For more information about the command syntax, see updKeyStoreCerts on page 12. f. Start the backup dynamic domain manager, by running: For backup dynamic domain manager V8.6.0 with related fix packs On Windows operating systems:

For more information about the command syntax, see User's Guide and Reference. 3. If dynamic domain managers are installed, to modify the dynamic domain managers keystore, perform the following steps for each dynamic domain manager:
35
a. Log on as Administrator on Windows operating systems, or as root on UNIX and Linux operating systems on the machine where the dynamic domain manager is installed. 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 dynamic domain manager by running: For dynamic domain manager V8.6.0 with related fix packs On Windows operating systems:

For more information about the command syntax, see User's Guide and Reference. e. Modify the keystore by running: For dynamic domain manager V8.6.0 with related fix packs On Windows operating systems:

For more information about the command syntax, see updKeyStoreCerts on page 12. f. Start the dynamic domain manager by running: For dynamic domain manager V8.6.0 with related fix packs On Windows operating systems:

Procedure to manage the default truststore and keystore for the Job Brokering Definition Console
36
BEGIN
2. Stop the JBDC
3. Modify the JBDC truststore
4. Modify the JBDC keystore
5. Start the JBDC
END
Legenda: JBDC Job Brokering Definition Console

Figure 7. Procedure to manage the default truststore and keystore for the Job Brokering Definition Console
Procedure to manage the default truststore and keystore for the Job Brokering Definition 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 Job Brokering Definition Console is installed. 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. 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 directory where you installed the certificates package and the <JBDC_INSTALL_DIR> is the directory where you installed the Job Brokering Definition Console.
37
4. Modify the keystore by copying the <PACKAGE_INSTALL_DIR>\TWS\ updCertsScripts\New\PRIVATE\WAS\TWSClientKeyfile.jks file file (private key) 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 Brokering Definition Console. 5. Start the Job Brokering Definition Console wizard.
Procedure to manage the default certificates for fault-tolerant agents 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: SSL Communication across the Tivoli Workload Scheduler network on page 3.
Procedure to manage the default truststore for fault-tolerant agents and domain managers
38
BEGIN
NO
Is DM installed?
YES
1. Modify the DM truststore
NO
Is BDM installed?
? YES
2. Modify the BDM truststore
NO
Is FTA installed?
YES
3. Modify the FTA truststore
END
Legenda: DM domain manager BDM backup domain manager FTA fault-tolerant agent
Figure 8. Procedure to manage the default truststore for fault-tolerant agents and domain managers
Procedure to manage the default truststore for fault-tolerant agents and domain managers 1. If domain managers are installed, to modify the domain managers truststore, perform the following steps for each domain manager:
39
a. Log on as Administrator on Windows operating systems, or as root on UNIX and Linux operating systems, on the machine where the domain manager is installed. 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 domain manager by running: For domain manager V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with related fix packs On Windows, UNIX and Linux operating systems:
conman "stop" conman "stopmon" conman "shut; wait"
For more information about the command syntax, see User's Guide and Reference. e. Modify the truststore by running: For domain manager V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with related fix packs On Windows operating systems:

For more information about the command syntax, see updTrustStoreCerts on page 9. f. Start the dynamic domain manager by running: For domain manager V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with related fix packs On Windows, UNIX, and Linux operating systems:
conman "start" conman "startmon"
For more information about the command syntax, see User's Guide and Reference. 2. If a backup domain manager is installed, to modify the backup domain managers truststore, perform the following steps for each backup 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 backup domain manager is installed. 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 backup domain manager by running: For backup domain manager V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with related fix packs On Windows, UNIX, and Linux operating systems:
40
For more information about the command syntax, see User's Guide and Reference. e. Modify the truststore by running: For backup domain manager V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with related fix packs On Windows operating systems:

For more information about the command syntax, see updTrustStoreCerts on page 9. f. Start the backup domain manager by running: For backup domain manager V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with related fix packs On Windows, UNIX, and Linux operating systems:
For more information about the command syntax, see User's Guide and Reference. 3. If fault-tolerant agents are installed, to modify the fault-tolerant agents truststore, perform the following steps for each fault-tolerant agent: a. Log on as Administrator on Windows operating systems, or as root on UNIX and Linux operating systems, on the machine where the backup domain manager is installed. 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 fault-tolerant agent by running: For fault-tolerant agent V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with related fix packs On Windows, UNIX, and Linux operating systems:
For more information about the command syntax, see User's Guide and Reference. e. Modify the truststore by running: For fault-tolerant agent V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with related fix packs On Windows operating systems:

For more information about the command syntax, see updTrustStoreCerts on page 9. f. Start the fault-tolerant agent by running:
41
For fault-tolerant agent V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with related fix packs On Windows, UNIX, and Linux operating systems:
Procedure to manage the default keystore for fault-tolerant agents and domain managers
42
BEGIN
NO
Is FTA installed?
YES
1. Modify the FTA keystore
NO
Is BDM installed?
? YES
2. Modify the BDM keystore
NO
Is DM installed?
? YES
3. Modify the DM keystore
END
Legenda: DM Domain Manager BDM Backup Domain Manager FTA fault-tolerant agent
Figure 9. Procedure to manage the default keystore for fault-tolerant agents and domain managers
Procedure to manage the default keystore for fault-tolerant agents and domain managers 1. If fault-tolerant agents are installed, to modify the fault-tolerant agents keystore, perform the following steps for each fault-tolerant agent:
43
a. Log on as Administrator on Windows operating systems, or as root on UNIX and Linux operating systems, on the machine where the backup domain manager is installed. 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 fault-tolerant agent by running: For fault-tolerant agent V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with related fix packs: On Windows, UNIX, and Linux operating systems:
For more information about the command syntax, see User's Guide and Reference. e. Modify the keystore by running: For fault-tolerant agent V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with related fix packs: On Windows operating systems:

For more information about the command syntax, see updKeyStoreCerts on page 12. f. Start 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 fix packs: On Windows, UNIX, and Linux operating systems:
For more information about the command syntax, see User's Guide and Reference. 2. If a backup domain manager is installed, to modify the backup domain managers keystore, perform the following steps for each backup 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 backup domain manager is installed. 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 backup domain manager by running: For backup domain manager V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with related fix packs: On Windows, UNIX, and Linux operating systems:
44
For more information about the command syntax, see User's Guide and Reference. e. Modify the keystore by running: For backup domain manager V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with related fix packs: On Windows operating systems:

For more information about the command syntax, see updKeyStoreCerts on page 12. f. Start the backup dynamic domain manager by running: For backup domain manager V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with related fix packs: On Windows, UNIX, and Linux operating systems:
For more information about the command syntax, see User's Guide and Reference. 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 domain manager is installed. 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 domain manager by running: For domain manager V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with related fix packs: On Windows, UNIX, and Linux operating systems:
For more information about the command syntax, see User's Guide and Reference. e. Modify the keystore by running: For domain manager V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with related fix packs: On Windows operating systems:

For more information about the command syntax, see updKeyStoreCerts on page 12. f. Start the dynamic domain manager by running:
45
For domain manager V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with related fix packs: On Windows, UNIX, and Linux operating systems:
46
Procedure to manage the default certificates for the connector APIs
BEGIN
2. Find the path of the old certificates
3. Stop the client
4. Re-place the truststore and keystore
5. Start the client
END
Legenda: API connector APIs

Figure 10. Procedure to manage the default certificates for the connector APIs
Procedure to manage the default certificates for the connector APIs 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 client for theconnector APIs is installed. 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.
47
2. Open the soap.client.props or ssl.client.props file to find the path of the TWSClientTrustFile.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 file and <PACKAGE_INSTALL_DIR>\TWS\DIR>\TWS\updCertsScripts\ New\TWSClientKeyFile.jks, where the <PACKAGE_INSTALL_DIR> is the directory where you installed the certificates package. 5. Start the client. Note: This procedure addresses the scenario described in Scenario: Custom integration based on Tivoli Workload Scheduler Java APIs on page 4.
Procedure to manage the default certificates for the Integration Workbench
BEGIN
2. Modify the SDK truststore
3. Modify the SDK keystore
END
Legenda: SDK Integration Workbench

Figure 11. Procedure to manage the default certificates for the Integration Workbench
Procedure to manage the default certificates for the Integration Workbench 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 Integration Workbench is installed.
48
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. 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 where you 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 where you installed the Integration Workbench. Note: This procedure addresses the scenario described in Scenario: Integration Workbench over SSL on page 4.
Procedure to manage the default truststore and keystore for command-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 default truststore and keystore for master domain manager command-line client. 2. To modify the default certificates for the remote command-lines clients, perform the Procedure to manage the default truststore and keystore for remote command-line client on page 51.
Procedure to manage the default truststore and keystore for master domain manager command-line client
49
BEGIN
? NO
CLISSLSERVERAUTH=yes in localopts?
YES
2. Find the old MDM CLIs certificates directory
3. Copy the new certificates from the package
END
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-line client
In the master domain manager instance, you have the following local command-lines: v composer v conman Procedure to manage the default truststore and keystore for the master domain manager command-line client If the variable CLISSLSERVERAUTH=no in the localopts file of the master domain manager You do not perform any actions because the SSL connection continues to work.
50
If the variable CLISSLSERVERAUTH=yes in the localopts file of the master domain 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 the master domain manager is installed. 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. 2. In the localopts file of the master domain manager, note the value of the variable CLISSLSERVERCERTIFICATE where you store the certificate for 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 the certificates package and the <RC_CERTS_DIR> is the directory where you store the certificate for the master domain manager.
Procedure to manage the default truststore and keystore for remote command-line client
BEGIN
2. Find the old CLI certificates directory
3. Copy the new CLI certificates from the package
END
Legenda: CLI remote comman-line client

Figure 13. Procedure to manage the default truststore and keystore for the remote command-line client
51
Procedure to manage the default truststore and keystore for the remote command-line client If you have remote command-lines installed for V8.3.0, V8.4.0, V8.5.0, V8.5.1.0, and V8.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 on UNIX and Linux operating systems, on the machine where the remote command-line client is installed. 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. 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 remote command-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 certificates package and the <RC_CERTS_DIR> is the directory where you store the certificate for remote command-line client.
Procedure to manage the default keystore for master domain manager, backup master domain manager, and agents with distributed connector
52
BEGIN
NO
Is BKM installed?
YES
1. Modify the BKM keystore
NO
Are agents installed with dist connector ?

YES
2. Modify the agents with connector keystore
3. Modify the MDM keystore
END
Legenda: MDM master domain manager BKM 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
Procedure to manage the default keystore for master domain manager, backup master domain manager, and agents with distributed connector 1. If a backup master domain manager is installed, to modify the keystore on the backup 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 backup master domain manager is installed. 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 backup master domain manager by running:
53
If the backup master domain manager you installed is V8.3.0 with related fix packs On Windows operating systems:

For more information about the command syntax, see User's Guide and Reference. e. Modify the keystore by running: 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 On Windows operating systems:

For more information about the command syntax, see updKeyStoreCerts on page 12. f. Start the backup master domain manager by running: If the backup master domain manager you installed is V8.3.0 with related fix packs On Windows operating systems:

For more information about the command syntax, see User's Guide and Reference. 2. Modify the keystore on the agents with distributed connector, by performing the following steps for each type of workstation with static scheduling and distributed connectors:
54
a. Log on as Administrator on Windows operating systems, or as root on UNIX and Linux operating systems, on the machine where the agent is installed. 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 agent with distributed connector by running: If the agent with distributed connector you installed is V8.3.0 with related fix packs On Windows operating systems:

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

conman "stop" conman "stopmon" conman "shut; wait" stopWas
For more information about the command syntax, see User's Guide and Reference. e. Modify the keystore by running: 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 On Windows operating systems:

For more information about the command syntax, see updKeyStoreCerts on page 12. f. Start the agent with distributed connector by running: If the agent with distributed connector you installed is V8.3.0 with related fix packs on Windows operating systems:
on UNIX and Linux operating systems:

55
If the agent 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 "start" conman "startmon" startWas.bat

conman "start" conman "startmon" startWas
For more information about the command syntax, see User's Guide and Reference. 3. Modify the keystore in the master domain manager 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 master domain manager is installed. 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 fix packs On Windows operating systems:

For more information about the command syntax, see User's Guide and Reference. e. Modify the keystore 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 On Windows operating systems:

For more information about the command syntax, see updKeyStoreCerts on page 12.
56
f. Start the master domain manager by running: If the master domain manager you installed is V8.3.0 with related fix packs On Windows operating systems:

conman "start" startWas.sh
If the master domain manager you installed is V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with related fix packs On Windows, UNIX and Linux operating systems:
Procedure to renew the default certificates for distributed components used in a z/OS environment
v If you use the default certificates in the z/OS connector for the following scenarios perform the Procedure to renew the default certificates for z/OS connector 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 Tivoli Workload Scheduler for z/OS agent (z-centric agent) and z/OS Controller on page 5, perform the Procedure to manage the default certificates for Tivoli Workload Scheduler for z/OS agent (z-centric) on page 69. v If you use the default certificates for the Scenario: Connection among dynamic domain managers and the z/OS Controller on page 6, perform the Procedure to manage the default certificates for dynamic domain managers connected to the z/OS Controller on page 73.
Procedure to renew the default certificates for z/OS connector on a distributed system
To modify the default certificates for scenarios described in Scenarios for distributed components in a z/OS environment on page 4, follow the steps listed in Figure 15 on page 58. You do not need to update your Tivoli Workload Scheduler environment with the following procedure steps all at the same time, but you must perform the entire procedure before the certificates expire on February 10, 2014.
57
BEGIN
NO
At least one default certificates used in the z/OS connector?

YES
procedure default truststore for z/OS connector
? NO
? NO NO
DWC or JSC with default certificates?
connector APIs with default certificates?

YES
Integration Workbench with default certificates?

YES
YES
procedure DWC/JSC
procedure connector APIs
procedure SDK
At least one of the previous procedures performed?

YES
NO
procedure default keystore for z/OS connector
END
LEGENDA: DWC Dynamic Workload Console JSC Job Scheduling Console SDK Integration Workbench
Figure 15. Procedure to renew the default certificates for z/OS connector on a distributed system
Procedure to renew the default certificates for z/OS connector on a distributed system
58
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 5 or Scenario: Connection between the Job Scheduling Console and the z/OS connector on a distributed system on page 5 or both, perform Procedure to manage the default truststore and keystore for the Dynamic Workload Console and 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 page 47. 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/OS connector
BEGIN
2. Stop the z/OS connector
3. Modify the z/OS connector truststore
4. Start the z/OS connector
END
Figure 16. Procedure to manage the default truststore for the z/OS connector
Perform the following steps: 1. Download and install the package by performing the following actions:
59
a. Log on as Administrator on Windows operating systems, or as root on UNIX and Linux operating systems, on the machine where the z/OS connector is installed. 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. 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, and V8.6.0 with related fix packs On Windows operating systems:

For more information about the command syntax, see updTrustStoreCerts on page 9. 4. Start the z/OS connector.
Procedure to manage the default truststore and keystore for the Dynamic Workload Console
60
BEGIN
2. Stop the DWC
3. Modify the DWC truststore
4. Modify the DWC keystore
5. Start the DWC
END
Legenda: DWC Dynamic Workload Console

Figure 17. Procedure to manage the default truststore and keystore for the Dynamic Workload Console
Procedure to manage the default truststore and keystore for the Dynamic Workload 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 Dynamic Workload Console is installed. 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. 2. Stop the WebSphere Application Server of the Dynamic Workload Console by running: On Windows operating systems:
stopWas.bat

stopWas.sh
61
For more information about the command syntax, see Tivoli Workload Scheduler: Administration Guide > Administrative tasks > Application Server tasks. 3. Modify the truststore by running: On Windows operating systems:

For more information about the command syntax , see updTrustStoreCerts on page 9. 4. Modify the keystore by running: On Windows operating systems:

For more information about the command syntax, see updKeyStoreCerts on page 12. 5. Start the Dynamic Workload Console by running: On Windows operating systems:
startWas.bat

startWas.sh
For more information about the command syntax, see Tivoli Workload Scheduler: Administration Guide > Administrative tasks > Application Server tasks. 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 asked to accept the new client truststore for the Dynamic Workload Console. Follow the procedure Accepting the new Dynamic Workload Console truststore when you stop the WebSphere Application Server for the first time on page 25. Accepting the new Dynamic Workload Console truststore when you stop the WebSphere Application Server for the first time: After you run the Procedure to manage the default truststore and keystore for the Dynamic Workload Console on page 23, when you stop the WebSphere Application Server for the first time, you are asked to accept the new client truststore for the Dynamic Workload Console. To accept the new truststore during the running of stopWas.bat on Windows operating 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 UNIX and Linux operating systems, by running the stopWas.sh script, you have the following output:
# ./stopWas.sh -direct -user twsuser -password twsuser ADMU0116I: Tool information is being logged in file /opt/ibm/TWATDWC/eWAS/profiles/TIPProfile/logs/server1/stopServer.log
62
ADMU0128I: Starting tool with the TIPProfile profile ADMU3100I: 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=US Issuer DN: CN=ServerNew, OU=TWS, O=IBM, C=US Serial number: 1352882899 Expires: Tue Nov 09 09:48:19 CET 2032 SHA-1 Digest: 5D:16:5D:17:3B:5F:BF:B7:EA:19:92:22:2D:36:53:1A:2F:9D:1B:26 MD5 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)y A retry of the request may need to occur if the socket times out while 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.
On Windows operating systems: If you stop the WebSphere Application Server for the first time on Windows operating systems, by running the stopWas.bat script from the wastools directory, you have the following output:
C:\TWA2\wastools>stopWas.bat The service is running. Service failed to stop. stopServer return code -10
Run the stopWas.bat from the embedded WebSphere Application Server binary directory and you have the following output:
C:\TWA2\eWAS\bin>stopServer.bat server1 ADMU0116I: Tool information is being logged in file C:\TWA2\eWAS\profiles\TIPProfile\logs\server1\stopServer.log ADMU0128I: Starting tool with the TIPProfile profile ADMU3100I: Reading configuration for server: server1 *** SSL SIGNER EXCHANGE PROMPT *** SSL signer from target host 9.168.125.163 is not found in trust store C:/TWA2/eWAS/profiles/TIPProfile/etc/TWSClientTrustFile.jks. Here is the signer information (verify the digest value matches what is displayed at the server): Subject DN: Issuer DN: Serial number: Expires: SHA-1 Digest: MD5 Digest: CN=ServerNew, OU=TWS, O=IBM, C=US CN=ServerNew, OU=TWS, O=IBM, C=US 1352882899 Mon Nov 08 20:48:19 GMT-12:00 2032 5D:16:5D:17:3B:5F:BF:B7:EA:19:92:22:2D:36:53:1A:2F:9D:1B:26 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)y A retry of the request may need to occur if the socket times out while 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 add ed to the trust store. ADMU3201I: Server stop request issued. Waiting for stop status. ADMU4000I: Server server1 stop completed.
63
Procedure to manage the default truststore and keystore for the Job Scheduling Console
BEGIN
2. Stop the JSC
3. Modify the JSC truststore
4. Modify the JSC keystore
5. Start the JSC
END
Legenda: JSC Job Scheduling Console

Figure 18. Procedure to manage the default truststore and keystore for the Job Scheduling Console
Procedure to manage the default truststore and keystore for the Job Scheduling 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 Job Scheduling Console is installed. 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. 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
64
where you installed the certificates package and the <JSC_INSTALL_DIR> is the directory 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 where you installed the certificates package and <JSC_INSTALL_DIR> is the directory where you installed the Job Scheduling Console. 5. Start the Job Scheduling Console wizard.
65
Procedure to manage the default certificates for the connector APIs
BEGIN
2. Find the path of the old certificates
3. Stop the client
4. Re-place the truststore and keystore
5. Start the client
END
Legenda: API connector APIs

Figure 19. Procedure to manage the default certificates for the connector APIs
Procedure to manage the default certificates for the connector APIs 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 client for theconnector APIs is installed. 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.
66
2. Open the soap.client.props or ssl.client.props file to find the path of the TWSClientTrustFile.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 file and <PACKAGE_INSTALL_DIR>\TWS\DIR>\TWS\updCertsScripts\ New\TWSClientKeyFile.jks, where the <PACKAGE_INSTALL_DIR> is the directory where you installed the certificates package. 5. Start the client. Note: This procedure addresses the scenario described in Scenario: Custom integration based on Tivoli Workload Scheduler Java APIs on page 4.
Procedure to manage the default certificates for the Integration Workbench
BEGIN
2. Modify the SDK truststore
3. Modify the SDK keystore
END
Legenda: SDK Integration Workbench

Figure 20. Procedure to manage the default certificates for the Integration Workbench
Procedure to manage the default certificates for the Integration Workbench 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 Integration Workbench is installed.
67
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. 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 where you 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 where you installed the Integration Workbench. Note: This procedure addresses the scenario described in Scenario: Integration Workbench over SSL on page 4.
Procedure to manage the default keystore for the z/OS connector
BEGIN
2. Stop the z/OS connector
3. Modify the z/OS connector keystore
4. Start the z/OS connector
END
Figure 21. Procedure to manage the default keystore for the z/OS connector
Procedure to manage the default keystore for the z/OS connector 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 z/OS connector is installed.
68
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. 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, and V8.6.0 with related fix packs On Windows operating systems:

For more information about the command syntax, see updKeyStoreCerts on page 12. 4. Start the z/OS connector.
Procedure to manage the default certificates for Tivoli Workload 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 then proceed 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 for the Job Brokering Definition Console on page 36. Note: This procedure addresses the scenario described in Scenario: Connection between Tivoli Workload Scheduler for z/OS agent (z-centric agent) and z/OS Controller 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 Workload Scheduler for z/OS agent (z-centric)
69
BEGIN
2. Stop the z-centric
3. Modify the z-centric truststore
4. Start the z-centric
END
Figure 22. Procedure to manage the default truststore for the Tivoli Workload Scheduler for z/OS agent (z-centric)
Procedure to manage the default truststore for the Tivoli Workload Scheduler for z/OS agent (z-centric) 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 Tivoli Workload Scheduler for z/OS agent (z-centric) is installed. 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. 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 is V8.5.1 and V8.6.0 with related fix packs On Windows operating systems:
ShutdownLwa.bat

ShutdownLwa
For more information about the command syntax, see User's Guide and Reference. 3. Modify the truststore by running:
70
If the Tivoli Workload Scheduler for z/OS agent (z-centric) you installed is V8.5.1 and V8.6.0 with related fix packs On Windows operating systems:

For more information about the command syntax, see updTrustStoreCerts on page 9. 4. Start 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 is V8.5.1 and V8.6.0 with related fix packs On Windows operating systems:
StartUpLwa.bat

StartUpLwa
Procedure to manage the default keystore for Tivoli Workload Scheduler for z/OS agent (z-centric)
71
BEGIN
2. Stop the z-centric
3. Modify the z-centric keystore
4. Start the z-centric
END
Figure 23. Procedure to manage the default keystore for the Tivoli Workload Scheduler for z/OS agent (z-centric)
Procedure to manage the default keystore for the Tivoli Workload Scheduler for z/OS agent (z-centric) 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 Tivoli Workload Scheduler for z/OS agent (z-centric) is installed. 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. 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 is V8.5.1 and V8.6.0 with related fix packs On Windows operating systems:
ShutdownLwa.bat

ShutdownLwa
For more information about the command syntax, see User's Guide and Reference. 3. Modify the keystore, by running:
72
If the Tivoli Workload Scheduler for z/OS agent (z-centric) you installed is V8.5.1 and V8.6.0 with related fix packs On Windows operating systems:

For more information about the command syntax, see updKeyStoreCerts on page 12. 4. Start 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 is V8.5.1 and V8.6.0 with related fix packs On Windows operating systems:
StartUpLwa.bat

StartUpLwa
Procedure to manage the default certificates for dynamic domain managers connected to the z/OS Controller
To manage the default certificates for dynamic domain managers connected to the z/OS Controller, follow the procedure described in Procedure to manage the default certificates for dynamic scheduling environment on page 28. Note: This procedure addresses the scenario described in Scenario: Connection among dynamic domain managers and the z/OS Controller on page 6. For the z/OS Controller, see the z/OS Controller documentation.
73
74
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 document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A. For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to: Intellectual Property Licensing Legal and Intellectual Property Law IBM Japan, Ltd. 19-21, Nihonbashi-Hakozakicho, Chuo-ku Tokyo 103-8510, Japan The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, 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 be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM websites are provided for convenience only and do not in any manner serve as an endorsement of those websites. The materials at those websites are not part of the materials for this IBM product 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 it believes appropriate without incurring any obligation to you. Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact: IBM Corporation 2Z4A/101 11400 Burnet Road Austin, 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 material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental.
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol ( or ), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the 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 registered trademarks 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 and Telecommunications Agency which is now part of the Office of Government Commerce. Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.
76
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. ITIL is a registered trademark, and a registered community trademark of The Minister for the Cabinet Office, and is registered in the U.S. Patent and Trademark Office UNIX is a registered trademark of The Open Group in the United States and other countries.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates.
Cell Broadband Engine is a trademark of Sony Computer Entertainment, Inc. in the United States, other countries, or both and is used under license therefrom. Linear Tape-Open, LTO, the LTO Logo, Ultrium, and the Ultrium logo are trademarks of HP, IBM Corp. and Quantum in the U.S. and other countries.
Notices
77
78
Index A
APIs certificates 47, 66 Job Scheduling Console certificates 27, 64
Z
zosconn certificates 59 keystore 68
K C
certificates APIs 47, 66 command-line client 49 dynamic workload console 23, 60 Integration Workbench 48, 67 Job Brokering Definition Console 36 Job Scheduling Console 27, 64 remote command-line client 51 zosconn 59 command-line client certificates 49 contents Package 8 keystore distributed connector 52 SSL environment 42 zosconn 68
P
package download 7 installing 8 Package contents 8 procedure default certificates
16, 57
D
default certificates dynamic environment 28 procedure 16, 57 scripts 9 SSL environment 38 Tivoli Workload Scheduler for z/OS agent 69 default keystore dynamic environment 32 Tivoli Workload Scheduler for z/OS agent (z-centric) 71 distributed connector keystore 52 truststore 18 Downloading package 7 dynamic environment default certificates 28 default keystore 32 Tivoli Workload Scheduler for z/OS agent (z-centric) 69 truststore 28 dynamic workload console certificates 23, 60
R
remote command-line client certificates 51
S
Scripts to renew default certificates 9 SSL environment default certificates 38 keystore 42 TrustStore 38
T
Tivoli Workload Scheduler for z/OS agent default certificates 69 Tivoli Workload Scheduler for z/OS agent (z-centric) default keystore 71 truststore distributed connector 18 dynamic environment 28 Tivoli Workload Scheduler for z/OS agent (z-centric) 69 TrustStore SSL environment 38
I
Installing package 8 Integration Workbench certificates 48, 67
U
updKeyStoreCerts 12 updTrustKeyStoreCerts updTrustStoreCerts 9 15
J
Job Brokering Definition Console certificates 36
79
80
Product Number: 5698-WSH
Printed in USA

Renewing Default Certificates For Tivoli Workload Scheduler

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Renewing Default Certificates For Tivoli Workload Scheduler

Transféré par

Droits d'auteur :

Formats disponibles

IBM Tivoli Workload Scheduler

Renewing default certificates for Tivoli Workload Scheduler

IBM Tivoli Workload Scheduler

Renewing default certificates for Tivoli Workload Scheduler

Chapter 2. How to renew the default certificates . . . . . . . . . . . . . 7

Renewing default certificates

Chapter 1. Scenarios affected by default certificates expiration

Scenarios for the distributed environment

Renewing default certificates

Scenario: SSL Communication across the Tivoli Workload Scheduler network

Chapter 1. Scenarios affected by default certificates expiration

Scenario: Custom integration based on Tivoli Workload Scheduler Java APIs

Scenario: Integration Workbench over SSL

Scenario: HTTPS for the command-line clients

Scenarios for distributed components in a z/OS environment

Renewing default certificates

Chapter 1. Scenarios affected by default certificates expiration

Renewing default certificates

Chapter 2. How to renew the default certificates

Downloading the package

Package V8.5.1 updCertsScripts_v851.zip Package V8.6.0 updCertsScripts_v860.zip

Installing the package

On UNIX, Linux, and IBM i operating systems

Renewing default certificates

Scripts to renew the default certificates

Chapter 2. How to renew the default certificates

Renewing default certificates

On UNIX, Linux, and IBM i operating systems:

Renewing default certificates

On UNIX and Linux operating systems: The script syntax is:

Renewing default certificates

On IBM i operating systems: The script syntax is:

On UNIX, Linux, and IBM i operating systems:

Chapter 2. How to renew the default certificates

On UNIX, Linux, and IBM i operating systems:

Procedure to renew the default certificates in a distributed environment

Renewing default certificates

at least one default certificate used in the MDM?

DWC or JSC with default certificates?

Dynamic environment with default certificates?

SSL across network with default certificates?

procedure Dynamic environment

procedure SSL network

connector APIs with default certificates?

Integration Workbench with default certificates?

CLIs with default certificates?

procedure connector APIs

At least one of the previous procedures performed?

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

Procedure to renew the default certificates in a distributed environment

Chapter 2. How to renew the default certificates

Renewing default certificates

1. Modify the MDM truststore

2. Modify the BKM truststore

Are agents installed with dist connector ?

3. Modify the agents with connector truststore

Chapter 2. How to renew the default certificates

On UNIX and Linux operating systems:

On UNIX and Linux operating systems:

On UNIX and Linux operating systems:

Renewing default certificates

On UNIX and Linux operating systems:

On UNIX and Linux operating systems: