Use the right keys to lock Workload Automation doors

Securing communications in the Workload Automation environment is an essential step to meet your company’s security requirements. Does Workload Automation use a secure communication mechanism? The answer is yes! All communication is implemented over SSL protocol TLSv1.2.

Workload Automation communication configuration involves the following scenarios:

• Master Domain Manager (MDM) and Dynamic Agents (DA).
• Master Domain Manager (MDM) and Dynamic Workload Console (DWC)
• Master Domain Manager (MDM) and fault-tolerant agents (FTA)

 
Default certificates are installed in the following keystores:
MDM:

• Private keys keystore: 

<TWS DATA DIR>\usr\servers\engineServer\resources\security\TWSServerKeyFile.jks

• Trusted keys keystore: 

<TWS DATA DIR>\usr\servers\engineServer\resources\security\TWSServerTrustFile.jks
 
DA:

• CMS (.kdb) keystore: 

<TWS DATA DIR>/ITA/cpa/ita/cert/TWSClientKeyStore.kdb

• .jks keystore: 

<TWS DATA DIR>/ITA/cpa/ita/cert/TWSClientKeyStoreJKS.jks
Keystores contain the same keys, both private and trusted.
 
DWC:

• Private key keystore:

<DWC_DATA_DIR>\usr\servers\dwcServer\resources\security\TWSServerKeyFile.jks

• Trusted key keystore:

<DWC_DATA_DIR>\usr\servers\dwcServer\resources\security\TWSServerTrustFile.jks
 
Why is it recommended to customize default certificates?

• To have stronger keys and prevent a vulnerability scan from detecting problems due to weak certificates.
• To replace self-signed certificates with verified CA certificates and avoid certificate problems with most browsers when connecting to the DWC.

 
Where do I start when customizing certificates? To begin with, create a new self-signed certificate or request new private keys from your Certification Authority (CA) and import them in the appropriate keystore. After that, extract public certificates from the new keys and distribute them to the correct communication parties. Figures 1 and 2 show where the key exchange takes place.

At the end of this article you will find the command reference for each action illustrated above.
 
Seven crucial questions for real-world scenarios 
1. What happens if I’m changing the key for MDM? Distribute the public certificates to both DA and DWC.
 
2. What happens if I’m changing the key for DA? Trust the public certificate to the MDM.
 
3. What happens if I’m changing the key for DWC? Replicate the same change on the MDM
 
4. What about key customization on Backup Master Domain Manager (BKM)? It is recommended to align BKM keystores with the ones on the MDM by replacing them with the customized ones. As a rule, the BKM plays the role of MDM in the communication diagrams shown above.

5. What about key customization on Dynamic Domain Manager (DDM) and backup Dynamic Domain Manager (BDDM)? It is recommended to align BDDM keystores to the ones in the DDM by replacing them with the customized ones. As a rule, the DDM plays the role of MDM in the communication with DA and the role of DWC in the communication with MDM. The change in the DDM key impacts both MDM and managed DAs.
 
6. Can I create new keystores on MDM, DWC, BKM, DDM, and BDDM? Yes, create them before customizing the certificates and follow this procedure to reflect the changes into the component:

1. Create one keystore for the keys and one keystore for the trusted keys in the .jks format and save them in the same folders as the previous files.
2. Add the files in the ssl_variables.xml file, located in <installation_dir>/usr/servers/<server_name>/configDropins/overrides
3. Update the following variables with the new values:

• keyStore.location
• keyStore.password
• trustStore.location
• trustStore.password

 
7. Can I create new keystores on DA? Yes, create the CMS keystore (.kdb) before customizing the certificates and distribute the keys as explained earlier, then create the jks keystore by using our twsManageKey conversion utility. To reflect the changes on the component, follow this procedure:

1. Stop the dynamic agent using the ShutDownLwa command. 
2. Edit the following keys in the < TWA_DATA_DIR>/ITA/cpa/ita/ita.ini file: 

o   key_db_name = file name of the kdb generated (CMS)
o   key_repository_dir = path to the kdb generated
o   java_truststore_password_file = absolute path to the sth  generated (pwd = default)
o   java_truststore_file = absolute path to the jks generated
Restart the dynamic agent using the StartUpLwa command. At last, to verify that the certificate customization has completed successfully, delete the old certificates and optionally rename the new certificates with the names of deleted certificates.
Now, all impacted components should be able to communicate as efficiently as before the certificate customization.
 
Command reference 
Here is the list of commands used to manage certificates.
CMS (.kdb) keystore certificates require the GSKIT command line: gsk8capicmd. To run the GSKIT command line, first source the TWA environment from the installation directory:

• WINDOWS: twa_env.cmd
• UNIX:. ./twa_env.sh

 
To manage certificates in JKS keystores, use the Java keytool command line available in:
<installation_directory>/JavaExt/jre/bin/keytool
 
To import a certificate, run the following command:

• <keytool> -importkeystore -srckeystore <source keystore> -destkeystore <destination keystore> -srcalias <certificate name in source keystore> -destalias <desired name of the certificate in destination keystore> -srcstorepass <password of source keystore> -deststorepass <password of destination keystore>
• <gskit> -cert -import -db <source keystore> -pw <source keystore password> -target <destination keystore> -target_pw <destination keystore password> -label <certificate name>

 
To add a certificate, run the following command:

• <keytool> -importcert -file <certificate file> -keystore <keystore name>   -alias <desired certificate name in keystore> -trustcacerts -storepass <keystore password>
• <gskit> -cert -add -db <keystore name> -pw <keystore password> -file <certificate file> -label <desired certificate name into keystore> -trust enable

 
To extract a certificate, run the following command:

• <keytool> -exportcert -keystore <keystore name> -alias <name of the certificate> -file $<file to extract into> -storepass <keystore password>
• <gskit> -cert -extract -db <keystore name> -pw <keystore password> -label <certificate name> -file <file to extract the certificate into>

 
To delete a certificate, run the following command:

• <keytool> -delete -alias <certificate name> -keystore <keystore name> -storepass <keystore password>
• <gskit> -cert -delete -db <keystore name> -pw <keystore password> -label <certificate name>

 
To rename a certificate, run the following command:

• <keytool> -changealias -keystore <keystore name> -storepass <keystore password> -alias <old certificate name> -destalias <new certificate name>
• <gskit> -cert -rename -db <keystore name> -pw <keystore password> -label <old certificate name> -new_label <new certificate name>

 
To list a certificate, run the following command:

• <keytool> -list -keystore <keystore name> -storepass <keystore password>
• <gskit> -cert -list -db <keystore name> -pw <keystore password>