TLS/SSL Considerations for Automic Automation
Securing the communication between the different components that make up your system is imperative. Especially with cloud communication, all data must be encrypted.
As of version 21, the Automic Automation uses TLS/SSL server authentication - an industry standard - to secure the communication between different components. Automic Automation also uses certificates to authenticate the identity of those partners to the component to which they need to establish a connection.
Important! Check Broadcom Software Academy. There is a course available for this topic. For more information, see the Education section at the end of this topic.
This page includes the following:
TLS/SSL Implementation Overview
The chart below depicts the process required for the TLS/SSL implementation and helps you understand not only the components involved but also the process itself.
Click the image to expand it.
The communication between the Automation Engine and the different components uses TLS/SSL through a secure WebSocket (WSS). These components establish a connection with the Java communication process (JCP) and/or the REST process (REST), which use trusted certificates to prove their identity to other communication partners, such as Agents.
Therefore, you have to decide which kind of certificates you are going to use to secure the communication in your system. This decision must be considered carefully, as it determines not only how secure the connections are but also the time and effort you have to invest in renewing and deploying the certificates.
Important! TLS/SSL Agents (in containers and on-premises) as well as the TLS Gateway, when used for the Automic Automation Kubernetes Edition, establish a connection to an ingress / HTTPS load balancer, which requires a certificate for authentication.
Make sure that address of the load balancer is defined on both sides: the Automation Engine and the Agent / TLS Gateway and that your HTTPS load balancer has the required certificates in place. For more information, see Connecting to AWI, the JCP and REST Processes Using an Ingress.
Automic Automation Administrators and TLS/SSL
Most companies have security and certificate policies in place and have a person or group that is in charge of creating, distributing and maintaining certificates - including renewing certificates - in the company. Most likely, your company uses either a public or internal Certificate Authority (CA) to sign certificates. Please contact that person or team to find out how your company deals with certificates and how to get the relevant certificates for Automic Automation.
Important! As an Automic Automation administrator, you do not have to take over these responsibilities (unless you are using self-signed certificates in a testing environment). However, you should have a basic understanding of TLS/SSL and certificates, which options there are and how do they work, so that you can better understand which security infrastructure you require for your Automic Automation environment. You have to make sure you understand ALL these concepts before planning the upgrade.
Basic Concepts when Using TLS/SSL
As a system administrator, you need to understand the basic concepts of TLS/SSL to better understand how to secure your Automic Automation system. Make sure that you review the following issues:
-
What is TLS/SSL? How does a TLS/SSL handshake work?
-
What is a certificate? Why are certificates used? Why are they necessary?
-
Which are the most common tools to create certificates (Java Keytool, OpenSSL in Linux, Keystore Explorer in Windows)?
-
What is a Certificate Authority (CA)?
-
Why are certificates signed?
-
What is the difference between certificate signed by an internal CA and a public CA?
-
What are self-signed certificates and which are the disadvantages of using them?
-
What is a keystore / key and which formats are used?
-
What is a private/public key pair?
-
What is a Certificate Signing Request (CSR)? What does a CSR consist of?
-
What is a Common Name (CN)?
-
What is a Subject Alternative Name (SAN)?
-
What does it mean to have a CA root/admin certificate in place and how do they allow the Agent to log on?
Considerations Before Installing Version 21 or Higher
Make sure you consider the following issues before upgrading to or installing Automic Automation version 21 or higher:
-
If your company already uses certificates signed by a third-party CA, can they also be used for Automic Automation?
-
Do you need to comply with strict security standards when using Automic Automation, especially in production environments?
-
Who is in charge of managing certificates and is there a dedicated person or team in charge of the Public Key Infrastructure (PKI) in the company?
-
Who is responsible for installing and/or distributing certificates and configuring TLS/SSL for Automic Automation?
-
How many certificates do you require? Only a couple for your Automic servers, or do you have to manage multiple servers spread across many locations and need to have a centralized view?
-
How important is connection security? What is the worst that could happen if a certificate expires or is compromised?
Based on the requirements and resources of your company, you can decide which type of TLS/SSL certificate to use.
Types of Certificates
Automic Automation supports three types of certificates to secure the communication. It is recommended using one of the CA signed options. The difference among them lies in how the certificates are created.
Important!
-
If your company already uses certificates signed by a public or internal CA, you only need to contact the person or team in charge of certificates and follow your company's procedure to obtain the relevant certificates.
-
As an Automic Automation administrator, when you use certificates signed by a CA, you do not have to create certificates nor configure anything for the Automic Web Interface nor for the Agents / TLS Gateway. You only have to check that the root certificates already are in the Java TrustStore or OS store.
-
If you do not want to use the default location used by the Java TrustStore or OS store to store the certificates, make sure you use the trustedCertFolder= in the respective configuration (INI) file to define the path to the folder where the trusted certificates are stored.
This section is meant to give you a brief overview only.
For additional information about the different certificate types and examples of how they could be created and used, see What Kind of Certificates Should I Use for Automic Automation v21.
Important! Please note that these are only examples, not a requirement for Automic Automation and they are not meant to replace the product documentation.
Certificates Signed by a Public Certificate Authority (CA)
Certificates signed by a public Certificate Authority (CA), such as IdenTrust, DigiCert, Let’s Encrypt, GlobalSign, and so on, usually are already trusted by different operating systems and/or applications. This eliminates the effort of deploying these certificates to all the relevant hosts.
It is recommended using certificates signed by a public CA when you are working with production environments and applications that are Internet facing.
In this case, the public CA of your choice provides you with the certificates you need. The relevant companies provide specific tools or APIs to do so. CA root/admin certificates are usually used only to sign intermediate certificates that can then verify the identities of end domains.
Certificates Signed by an Internal Certificate Authority (CA)
You can use certificates signed by a company-wide, internal Certificate Authority (CA), for example, when you are working in a testing environment or using applications that are not Internet facing.
You have to raise a Certificate Signing Request (CSR) which gets signed by the CA root certificate. The reply of the CSR is the server certificate that you load to the truststore of the Automation Engine.
Make sure that the trusted certificates are deployed on the respective hosts.
Since the server certificate(s) can have a shorter lifespan, the validity period of the CA root/admin certificate can be longer.
Self-Signed Certificates
Using self-signed certificates allows you to manage the security of your Automic Automation system without involving a third-party. In this case, the Automic Automation administrator is responsible for renewing and distributing certificates to all hosts.
Important! It is not recommended using self-signed certificates outside a testing environment.
As an Automic Automation administrator, you can create self-signed certificates using tools such as Java Keytool, OpenSSL, or the KeyStore Explorer. To do so, you have to create a keystore using the PKCS#12 format and save the keystore file in a secure location. Then you have to generate the key pair and define the validity period and further certificate details.
Note: Update cn= to the JCP server's fully qualified domain name and ou=, o=, l=, and c= to fit your environment.
Java Keytool example
Example for server called 24JLZY2
keytool -genkeypair -alias jetty -keyalg RSA -storetype PKCS12 -keypass changeit -storepass changeit -keystore httpsKeyfile -validity 365 -keysize 2048 -dname "cn=24JLZY2, ou=Automic, o=Broadcom, l=Vienna, c=AT"
Once you have your self-signed certificates in place, you have to deploy them to the respective TLS/SSL keystore, and configure the Automation Engine and the respective TLS/SSL component to work with your certificates.
-
Deploying the certificates to the keystore and configuring the AE
You have to create encoded passwords for the keystore connections, configure the AE INI file (ucsrv.ini) accordingly and deploy the certificates the target server before starting the Automation Engine and testing your connections.
-
Configuring AWI
Import the server certificates in Java certificate truststore (cacerts) or set the trustedCertFolder= parameter the AWI configuration file (uc4config.xml) accordingly before restarting the Automic Web Interface.
-
Configuring the TLS/SSL Components (Agents, TLS Gateway, and so on)
Configure the path to the certificate you are using in the [AUTHORIZATION] section of the INI file of the relevant TLS/SSL Agent or TLS Gateway or use the Java TrustStore or OS store to import the respective certificates.
Certificate Requirements for Automic Automation
Once you are familiar with the basic concepts in TLS/SSL and certificates, make sure the certificates you get meet the requirements for the Automation Engine
General Requirements
The JCP and REST processes use trusted certificates to prove their identity to other communication partners, such as AWI, and the Java, Windows, and UNIX Agents.
The Automic Automation TLS/SSL implementation uses public key certificates in X.509 format and TLS version 1.2 for the secure connections between the server (Automation Engine) and the hosts (AWI, Agents, and so on).
The Java default cipher suite of the JCP is used to configure the TLS/SSL connection. You can change the supported cipher suites in the Java security policy. For more information, see https://www.java.com/en/configure_crypto.html.
Using Subject Alternative Names (SAN)
Every IP Address and server/hostname used in Automic Automation must exist in the certificate. Therefore, high-availability environments, multiple network cards, different internal and external addresses, DNS aliases or numerous JCPs across different servers, all require a Subject Alternative Names (SAN) definition.
Note: If a Subject Alternative Name (SAN) has been defined, the Common Name (CN) must be repeated in the SAN list because the Common Name is ignored when Subject Alternative Names are present.
TLS/SSL Handshake
The TLS/SSL handshake is the mechanism used to authenticate the communication partners. This section explains how the standard TLS/SSL handshake works specifically in the context of Automic Automation and which elements must be in place for it to work.
Important! As an Automic Automation administrator, you do not need to create and distribute certificates. You only need to contact the person or team in charge of certificates in your company to find out how to reach the relevant certificates.
There are two sides to the TLS/SSL handshake:
-
the AE/server side (JCP and/or REST processes)
-
the component/host side (AWI, the Agents, and so on)
The host establishes the connection to the AE. The AE then sends the public key section of the certificate to the host, which in turn, searches through the default locations in the operating system and verifies the certificate.
The host verifies if its connection parameters to the AE match the server names in the certificates. If they do not match, they cannot establish a connection. For example, servername is not equal to servername.fqdn.
On the Automation Engine/server side, make sure that the certificates are available on the AE server as well as on the host in which the JCP/REST processes are installed.
On the host side (AWI, Agents, and so on), if you do not want to use the default location used by the Java TrustStore or OS store to store the certificates, make sure you use the trustedCertFolder= in the respective configuration (INI) file to define the path to the folder where the trusted certificates are stored.
Renewing Expired Certificates
You have to make sure that the certificates being used not only meet the respective security requirements, but also are not expired. Otherwise, the components cannot connect to the Automation Engine.
The system checks the certificate expiration date every 24 hours (at midnight UTC). When one or more certificates is close to expiring, that is, if the expiration date is within 30 days, AWI displays the following notification: "The following JCP certificates will expire within the next 30 days: <certificate name (expiration date)>". The expiration date of the certificate is also written into the JCP log file on startup as well as at midnight (UTC).
The notification is displayed in all Clients but only to users with the privilege Access to Administration, see Granting Automation Engine Privileges .The notification remains visible until the certificate is renewed.
Notes:
-
AWI displays only one notification even if there is more than one certificate about to expire. All relevant certificates are listed one after the other separated by a comma sorted by expiration date; the certificate closest to the expiration date is listed first.
-
It is not necessary to restart the JCP after renewing the certificate.
-
Make sure that the new certificate is set correctly and uses the same definition as the TLS section of the INI file of the Automation Engine, see Automation Engine. Otherwise, the old KeyStore definition is used and the JCP will not start.
Optionally, you can also use the UC_SERVER_TLS_SETTINGS variable to trigger a custom action if one of these certificates is close to expiring. For more information, see UC_SERVER_TLS_SETTINGS - Server Certificate Management.
If the expiration date is close, for example, within the next one to three months, and you use a certificate signed by an external or internal Certificate Authority (CA), make sure you inform the relevant people. That could be either your Automic Automation administrator or the person or team in charge of security in your company. They might need to raise a Certificate Signing Request (CSR) to get the certificate signed by the CA root certificate.
The new certificates must be created either on for each JCP or one certificate including all JCP domain names. Also, the keystore name, keystore password, key password and key alias should not change; otherwise the corresponding INI file parameters must be adapted, which in turn requires restarting the JCP.
Once the new certificates are in ready, they must be deployed to all JCPs (for example, using a File Transfer). If the INI file does not change, then there is no need to restart the JCPs.
After the certificates for the JCPs have been renewed and deployed, make sure to check if the certificates for the Agents also need updating. Consider the following:
-
If a new certificate is signed by the same CA as the initial one and if the root/intermediate certificates of the CA are already in the respective truststore (OS or Java) on the Agent's hosts (which should be the case), then nothing has to be done. The Agent trusts the CA that signed the new certificate; therefore, they automatically trust the server certificate.
-
If you are using new self-signed certificates, the Agents need to trust them directly. That means that the new self-signed certificates must be deployed again to all Agents (like the first time they were deployed). That can be done either by copying them to a trustedcertfolder or installing them in the OS or Java truststore.
Finding TLS/SSL Information in this Documentation
The documentation includes the information relevant to the TLS/SSL implementation where you need to use it. This means that, for example, you will find information about the TLS/SSL implementation for an Agent in the corresponding Agent documentation page. The same is valid for all other components that require you to set up TLS/SSL.
However, it is important you find the information you need regardless of your entry point to the documentation:
Note: This refers to the mandatory TLS/SSL server authentication implementation introduced in version 21 for the communication between the Automation Engine and the different components.
TLS/SSL and the Security Section
The Administering and Configuring section of the documentation has many pages dedicated exclusively to the security of your system. This section includes the following TLS/SSL:
-
TLS/SSL Certificate Considerations
Note: This page is included in different sections of the documentation to make sure you can access it where you need it.
TLS/SSL and the AE Installation
The Installation section of the documentation includes the TLS/SSL information you need to prepare for the installation. It also includes information where required in the installation process.
For the manual installation of an on-premises system:
For the Automic Automation Kubernetes Edition:
TLS/SSL and the Agent Installation
The Windows, UNIX, and Java Agents, that is the SQL, JMX, PeopleSoft, RA core, SAP, and IA (Analytics) Agents, use TLS/SSL to establish the connection to the Automation Engine.
-
For the manual agent installation, see Installing the Agents Manually
-
For the containerized agent installation, see Installing Containerized Agents
TLS/SSL and the AE Upgrade
The Upgrade section of the documentation includes the TLS/SSL information you need to prepare for the upgrade. It also includes information where required in the upgrade process.
For the manual upgrade of an on-premises system:
For the Automic Automation Kubernetes Edition:
-
Container-Based System Upgrade - Automic Automation Kubernetes Edition
-
Connecting to AWI, the JCP and REST Processes Using an Ingress
TLS/SSL and Java components, Proxy , and TLS Gateway
These components also require TLS/SSL security:
- Internal Web Services, see Configuration WebInterface for the Internal Webservice
- Java API, see Using the AE Application Interface
- Proxy
- TLS Gateway
Education
The Broadcom Software Academy provides a wide range of free online trainings. For information about how to navigate through the Academy and on how to register for courses, see Free Online Courses.
The following course(s) are associated with this topic: