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. Read this blog to find out how to implement security correctly in a v9.5 environment by customizing default certificates.
Workload Automation communication configuration involves the following scenarios:
Default certificates are installed in the following keystores:
Keystores contain the same keys, both private and trusted.
Why is it recommended to customize default certificates?
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:
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:
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.
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:
To manage certificates in JKS keystores, use the Java keytool command line available in:
To import a certificate, run the following command:
To add a certificate, run the following command:
To extract a certificate, run the following command:
To delete a certificate, run the following command:
To rename a certificate, run the following command:
To list a certificate, run the following command: