IBM Tivoli Workload Scheduler
Renewing default certificates for Tivoli
Workload Scheduler
Version 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
Version 8.3.0 8.4.0 8.5.0 8.5.1 8.6.0
Note
Contents
Chapter 1. Scenarios affected by default
certificates expiration . . . 1
Scenarios for the distributed environment . . . . 1
Scenario: Connection between the Dynamic Workload Console and agent with a distributed connector . . . 2
Scenario: Connection between the Job Scheduling Console and agent with a distributed connector . 2 Scenario: Connection among dynamic agents and the master domain manager or dynamic domain manager . . . 2
Scenario: SSL Communication across the Tivoli Workload Scheduler network . . . 3
Scenario: Custom integration based on Tivoli Workload Scheduler Java APIs . . . 4
Scenario: Integration Workbench over SSL . . . 4
Scenario: HTTPS for the command-line clients . . 4
Scenarios for distributed components in a z/OS environment . . . 4
Scenario: Connection between the Dynamic Workload Console and the z/OS connector in a distributed system . . . 5
Scenario: Connection between the Job Scheduling Console and the z/OS connector on a distributed system . . . 5
Scenario: Connection between Tivoli Workload Scheduler for z/OS agent (z-centric agent) and z/OS Controller . . . 5
Scenario: Connection among dynamic domain managers and the z/OS Controller . . . 6
Chapter 2. How to renew the default
certificates
. . . 7
Downloading the package . . . 7
Installing the package . . . 8
Package contents . . . 8
Scripts to renew the default certificates . . . 9
updTrustStoreCerts . . . 9
updKeyStoreCerts . . . 12
updTrustKeyStoreCerts . . . 15
Procedure to renew the default certificates in a distributed environment . . . 16
Procedure to manage the default truststore for master domain manager, backup master domain manager, and agents with distributed connector . 18 Procedure to manage the default truststore and keystore for the Dynamic Workload Console and Job Scheduling Console . . . 23
Procedure to manage the default certificates for dynamic scheduling environment . . . 28
Procedure to manage the default certificates for fault-tolerant agents and domain managers in the SSL environment . . . 38
Procedure to manage the default certificates for the connector APIs . . . 47
Procedure to manage the default certificates for the Integration Workbench . . . 48
Procedure to manage the default truststore and keystore for command-line client . . . 49
Procedure to manage the default keystore for master domain manager, backup master domain manager, and agents with distributed connector . 52 Procedure to renew the default certificates for distributed components used in a z/OS environment . . . 57
Procedure to renew the default certificates for z/OS connector on a distributed system . . . . 57
Procedure to manage the default certificates for Tivoli Workload Scheduler for z/OS agent (z-centric) . . . 69
Procedure to manage the default certificates for dynamic domain managers connected to the z/OS Controller . . . 73
Notices
. . . 75
Trademarks . . . 76
Chapter 1. Scenarios affected by default certificates expiration
Tivoli Workload Scheduler provides a secure, authenticated, and encryptedconnection mechanism for communication based on the Secure Sockets Layer (SSL) protocol, which is automatically installed with Tivoli Workload Scheduler.
Tivoli Workload Scheduler also provides default certificates to manage the 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 conmancommands.
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 conmancommands.
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. 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 Master domain manager and its domain managers
v Master domain manager and fault-tolerant agents in the master domain v Master domain manager and backup master domain manager
v 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: 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 V8.4.0 v V8.5.0 v V8.5.1 v V8.6.0
For more information about how to download the package for the version 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 Newdirectory that contains new defaults certificates v Olddirectory 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.propertiesfile 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>
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
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.propertiesfile 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
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
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 <INSTALL_DIR>/TDWB_CLI/certs/TWSClientKeyFile.jks v <INSTALL_DIR>/TWS/ITA/TWSClientKeyStore.kdb v <INSTALL_DIR>/TWS/ssl/OpenSSL/TWSClient.key v <INSTALL_DIR>/TWS/ssl/OpenSSL/TWSClient.cer
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 On IBM i 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, 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" On UNIX, Linux, and IBM i operating systems:
./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:
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:
./updKeyStoresCerts.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. 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" On UNIX, Linux, and IBM i operating systems:
./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.
Procedure to renew the default certificates in a distributed environment
procedure default truststore for MDM,
BKM, agents with dist connector
procedure Dynamic environment
procedure SSL network
procedure
connector APIs proceduresdk procedure
CLIs
procedure default keystore for MDM, BKM, agents with dist connector
YES YES
YES YES YES
NO NO NO NO NO NO NO BEGIN END YES YES YES
at least one default certificate
used in the MDM?
NO
?
Dynamic environment
with default certificates?
?
SSL across network
with default certificates?
?
connector APIs with
default certificates?
?
Integration Workbench with
default certificates?
CLIs with
default certificates?
?
connector APIs with
default certificates?
?
At least one of the
previous procedures
performed?
LEGENDA:
MDM master domain manager BKM backup master domain manager DWC Dynamic Workload Console JSC Job Scheduling Console CLI command-line client
?
DWC or JSC with
default certificates?
procedure DWC/JSC
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 the“Procedure 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
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.
?
Is BKM installed?
NO BEGIN YES ?Are agents installed
with dist connector ?
NO
YES
END
1. Modify the MDM truststore
2. Modify the BKM truststore
3. Modify the agents with connector truststore
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
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 "stop"
conman "stopmon" conman "stopappserver" conman "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
On UNIX and Linux operating systems: updTrustStoresCerts.sh
For more information about the command syntax, see “updTrustStoreCerts” on page 9.
f. Start the master domain manager by running:
If the master domain manager you installed is V8.3.0 with related fix packs
On Windows operating systems: conman "start"
startWas.cmd
On UNIX and Linux 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: conman "start"
conman "startmon" conman "startappserver"
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: conman "stop"
conman "shut; wait" stopWas.cmd
On UNIX and Linux operating systems: conman "stop"
conman "shut; wait" stopWas
If the backup master domain manager you installed is V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with related fix packs
On Window, UNIX, and Linux operating systems: conman "stop"
conman "stopmon" conman "stopappserver" conman "shut; wait"
For 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: updTrustStoresCerts.bat
On UNIX and Linux operating systems: updTrustStoresCerts.sh
For more information about the command syntax, see “updTrustStoreCerts” on page 9.
f. Start the 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.cmd
On UNIX and Linux operating systems: conman "start"
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: conman "start"
conman "startmon" conman "startappserver"
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: conman "stop"
conman "shut; wait" stopWas.cmd
On UNIX and Linux operating systems: conman "stop"
conman "shut; wait" stopWas
If the agent with distributed connector you installed is V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with related fix packs
On Windows operating systems: conman "stop"
conman "stopmon" conman "shut; wait" stopWas.bat
On UNIX and Linux operating systems: conman "stop"
conman "stopmon" conman "shut; wait" stopWas
For 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: updTrustStoresCerts.bat
On UNIX and Linux operating systems: updTrustStoresCerts.sh
For more information about the command syntax, see “updTrustStoreCerts” on page 9.
If the agent with distributed connector you installed is V8.3.0 with related fix packs
On Windows operating systems: conman "start"
startWas.cmd
On UNIX and Linux operating systems: conman "start"
startWas
If the agent you installed is V8.4.0, V8.5.0, V8.5.1, and V8.6.0 with related fix packs
On Windows operating systems: conman "start"
conman "startmon" startWas.bat
On UNIX and Linux operating systems: conman "start"
conman "startmon" startWas
For more information about the command syntax, see User's 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
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
On UNIX and Linux operating systems: stopWas.sh
BEGIN
END
Legenda:
DWC Dynamic Workload Console
1. Download and install the package
2. Stop the DWC
5. Start the DWC
3. Modify the DWC truststore
4. Modify the DWC keystore
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:
updTrustStoresCerts.bat
On UNIX and Linux operating systems: updTrustStoresCerts.sh
For more information about the command syntax , see “updTrustStoreCerts” on page 9.
4. Modify the keystore by running: On Windows operating systems:
updKeyStoresCerts.bat
On UNIX and Linux operating systems: updKeyStoresCerts.sh
For more information about the command syntax, see “updKeyStoreCerts” on page 12.
5. Start the Dynamic Workload Console by running: On Windows operating systems:
startWas.bat
On UNIX and Linux operating systems: 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
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 wastoolsdirectory, 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: CN=ServerNew, OU=TWS, O=IBM, C=US
Issuer DN: CN=ServerNew, OU=TWS, O=IBM, C=US Serial number: 1352882899
Expires: Mon Nov 08 20:48:19 GMT-12:00 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 add
ed to the trust store.
ADMU3201I: Server stop request issued. Waiting for stop status. ADMU4000I: Server server1 stop completed.
Procedure to manage the default truststore and keystore for 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.jksfile to the directory <JSC_INSTALL_DIR>\keyswhere the <PACKAGE_INSTALL_DIR> is the directory
BEGIN
END
Legenda:
Job Scheduling Console
JSC
1. Download and install the package
2. Stop the JSC
5. Start the JSC
3. Modify the JSCtruststore
4. Modify the JSC keystore
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.jksfile to the directory <JSC_INSTALL_DIR>\keyswhere <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
1. If the dynamic domain managers are installed, to modify the dynamic domain managers truststore, perform the following steps for each dynamic domain manager: ?
Is DDM installed?
NO BEGIN YES ?Is DA installed?
NO YES END2. Modify the BDDM truststore
3. Modify the dynamic agent truststore
Legenda: DDM d
BDDM backup dynamic domain manager DA dynamic agent
ynamic domain manager
1. Modify the DDM truststore
?
Is BDDM installed?
YES
NO
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
On UNIX and Linux operating systems: 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:
updTrustStoresCerts.bat
On UNIX and Linux operating systems: updTrustStoresCerts.sh
For more information about the command syntax, see “updTrustStoreCerts” on page 9.
f. Start the 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
On UNIX and Linux operating systems: 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.
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:
conman "stop" ShutdownLwa.bat conman "shut;wait" stopWas.bat
On UNIX and Linux operating systems: 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 backup dynamic domain manager V8.6.0 with related fix packs On Windows operating systems:
updTrustStoresCerts.bat
On UNIX and Linux operating systems: updTrustStoresCerts.sh
For more information about the command syntax, see “updTrustStoreCerts” on page 9.
f. Start the backup dynamic domain manager by running:
For backup dynamic domain manager V8.6.0 with related fix packs On Windows operating systems:
conman "start" StartUpLwa.bat startWas.bat
On UNIX and Linux operating systems: conman "start"
StartUpLwa startWas
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:
On Windows operating systems: ShutdownLwa.bat
On UNIX and Linux operating systems: 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:
updTrustStoresCerts.bat
On UNIX and Linux operating systems: updTrustStoresCerts.sh
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:
updTrustStoresCerts.bat
On UNIX, Linux, and IBM i operating systems: updTrustStoresCerts.sh
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
On UNIX and Linux operating systems: StartUpLwa
For dynamic agent V8.6.0 with related fix packs On Windows operating systems:
StartUpLwa.bat
On UNIX, Linux, and IBM i operating systems: StartUpLwa
For more information about the command syntax, see User's Guide and Reference.
Procedure to manage the default keystore for dynamic agents
1. If dynamic agents are installed, to modify the dynamic agents keystore, perform the following steps for each dynamic agent:
?
Is DA installed?
NO BEGIN YES ? NO YES END2. Modify the BDDM keystore
3. Modify the DDM keystore
Legenda: DDM d
BDDM backup dynamic domain manager DA dynamic agent
ynamic domain manager
1. Modify the DA keystore
?
Is BDDM installed?
? NO YES ?Is DDM installed?
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
On UNIX and Linux operating systems: 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 keystore by running:
For dynamic agent V8.5.1 with related fix packs On Windows operating systems:
updKeyStoresCerts.bat
On UNIX and Linux operating systems: updKeyStoresCerts.sh
For dynamic agent V8.6.0 with related fix packs On Windows operating systems:
updKeyStoresCerts.bat
On UNIX, Linux and IBM i operating systems: updKeyStoresCerts.sh
For more information about the command syntax, see “updKeyStoreCerts” on page 12.
f. Start the dynamic agent by running:
For dynamic agent V8.5.1 with related fix packs On Windows operating systems:
StartUpLwa.bat
On UNIX and Linux operating systems: StartUpLwa
For dynamic agent V8.6.0 with related fix packs On Windows operating systems:
StartUpLwa.bat
On UNIX, Linux, and IBM i operating systems: StartUpLwa
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:
conman "stop" ShutdownLwa.bat conman "shut;wait" stopWas.bat
On UNIX and Linux operating systems: conman "stop"
ShutdownLwa conman "shut;wait" stopWas
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:
updKeyStoresCerts.bat
On UNIX and Linux operating systems: updKeyStoresCerts.sh
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:
conman "start" StartUpLwa.bat startWas.bat
On UNIX and Linux operating systems: conman "start"
StartUpLwa startWas
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:
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
On UNIX and Linux operating systems: conman "stop"
ShutdownLwa conman "shut;wait" stopWas
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:
updKeyStoresCerts.bat
On UNIX and Linux operating systems: updKeyStoresCerts.sh
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:
conman "start" StartUpLwa.bat startWas.bat
On UNIX and Linux operating systems: conman "start"
StartUpLwa startWas
For more information about the command syntax, see User's Guide and Reference.
