Automic Workload Automation

 View Only

 Automic Automation V12 Upgrade to V21 - TSL/SSL Certificate Consideration

Tamman Montanaro's profile image
Tamman Montanaro posted Apr 01, 2024 04:39 PM

Hello Broadcom Support,

I have an interesting question regarding the TSL/SSL certificates used by the automation engine server. In our test environment, there is only one automation engine server with a self-signed certificate for the AWI/other v21 agents to utilize. In our production environment, there are two automation engine servers (H1 & H2) for dual usage. When we upgrade from v12.3 to v21 in our production environment, how should we handle the TSL/SSL certificate? 

We will be using a self-signed certificate for these backend automation engine servers (our front-end has a CA-certificate and is only exposed through VPN -- we are not concerned with security). Will I have to create two keystores for each server -- H1 and H2 -- or can I use one keystore with two key-pairs for each server? For the second option, I would then export the certificate per the associated key-pair for the respective server. Both servers would have a copy of the same keystore. What is recommended?

Thanks,

Tamman Montanaro

Arun Verma's profile image
Arun Verma

Hi Tamman,

To address your question, please refer to section "2.2.3 High Availability, Multiple Network Cards or JCPs on Multiple Servers" in the provided attachment.

The approach outlined involves utilizing Subject Alternative Name (SAN) and adding the respective SAN for all the JCP nodes. This enables the usage of a single certificate across the entire environment.

Points to note:

  • When dealing with scenarios such as multiple network cards on servers, varying internal and external addresses, or multiple JCPs across different servers, it's necessary to define each IP Address or Server Name in the certificate.
  • This can be accomplished by integrating Subject Alternative Names into the certificate.
  • Important note: If a Subject Alternative Name is defined, it's essential to repeat the Common Name in the Subject Alternative Names list. This is because the Common Name is disregarded when Subject Alternative Names are defined.

You can access the document through this link: Creating and Using TLSSSL Self-Signed Certificates for use with Automic Automation v21.pdf

Regards,

Arun

Klaus Lintz's profile image
Klaus Lintz

Hi Tamman

You can have only 1 keystore for all your servers and you require to export the certs and copy them to the relevant agents & AWI.

Regards

Klaus

Markus Embacher's profile image
Broadcom Employee Markus Embacher

Hi,

we recommend using a proper signed certificate (either by a public or internal CA) for production environments. Using self-signed certificates requires you to manage the certificate distribution yourself.

Regards, Markus

Tamman Montanaro's profile image
Tamman Montanaro

Hello @Arun Verma / @Klaus Lintz,

Using the one keystore, should I create two key pairs (two exported certificate) for each server or use just the one cert and include both server details within the SAN? 

Thanks,

Tamman Montanaro

Markus Embacher's profile image
Broadcom Employee Markus Embacher

Hi Tamman,

just one certificate. It is used to secure the connection from clients (agents, AWI, ...) to the Automation Engine. It only makes sense to have multiple server certificates if they are signed by different certificate authorities. Such requirement may come from different CA root certificates at the agents.

Regards, Markus