TLS/SSL Communication and Encryption

Secure communication between the components that integrate an Automation Engine system relies on encryption and authenticity. It secures the data flow between the components and ensures that data cannot be read or modified during transfer. As a system administrator, you configure the encryption of your system.

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:

Overview

Encryption is used for the following purposes:

Password storage within the Automation Engine database repository
Database password reference within the Automation Engine configuration file
Communication between Automation Engine instances and different components
Web interfaces and APIs
Outbound communication

For a more detailed overview of which components use TLS/SSL to secure the connection with their communication partners, see TLS/SSL Component Communication.

Network Communication

The Automation Engine uses the TCP/IP protocol family for data transmission. These protocols have been developed for fail-safe peripheral communication and are therefore very well suited for safe data transfer. TCP/IP needs relatively low effort for the design of redundant networks, thus making the design of highly available and fail-safe networks easy.

The security of the communication between each connection partner relies on encryption. Automic Automation uses TLS/SSL to ensure confidentiality, integrity and authenticity. The architecture consists of multiple certificates, which enable the client to verify the identity of the endpoint. The Automation Engine exposes a TLS/SSL endpoint through the Java communication process (JCP) to which agents can connect. To enable a painless integration, it is recommended to use a certificate that is already trusted in the client machines, such as a certificate signed by a trusted certificate authority (CA).

The Automation Engine deploys certificates automatically to the Agents. All certificates are handled and signed by the Automation Engine. There are no manual steps involved, which ensures an easy setup and removes the need of an additional certificate management process. For the initial setup, the Agent requires an authentication package used to register the new Agent in the system. During this initial setup, the Agent receives a certificate from the Automation Engine; the certificate is then used to authenticate against other Agents, for example, during file transfers. This ensures a secure communication between Agents without complicated setup.

Encryption

The Automation Engine only communicates with current Agents using TLS/SSL. An unencrypted communication is not possible, therefore a proper TLS/SSL setup of the JCP endpoint is required. For more information, see Securing Connections to the AE (TLS/SSL).

All other Agents establish a connection with a Communication Process (CP) and use an AES key level of your choice for encryption. For more information, see Non-TLS/SSL Communication and Encryption.

TLS/SSL Component Communication

This section gives you an overview of all TLS/SSL connections in the system.

TLS/SSL and the Automation Engine

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. These certificates are stored in a keystore, which must be created beforehand using pkcs12 format. The relevant parameters for the keystore and the keys are defined in the [TLS] section of the configuration (UCSRV.INI) file of the Automation Engine.

Note: The JCP and REST processes do not allow TLS/SSL clients to initiate a renegotiation.

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.

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.

More information:

TLS/SSL and the Automic Web Interface

The Automic Web Interface connects to the Automation Engine using TLS/SSL. However, it usually uses common security principles to connect to an application server. This is one of the most important components that influences the security of AWI.

You can enable the TLS/SSL for the communication between AWI and an application server.

More information:

TLS/SSL and PostgreSQL Database

The connection between a PostgreSQL database (DB Server v11 and higher) and the Automation Engine can be secure using TLS/SSL. This connection also requires a corresponding certificate. For more information ,see Preparing the AE Database - PostgreSQL.

TLS/SSL and the ServiceManager

The ServiceManager uses TLS 1.2 and CAPKI to establish secure connections to its clients, the ServiceManager - Service, the ServiceManager - Dialog Program, the ServiceManager - Command Line Program (CLI) and the Server Processes of the Automation Engine. Therefore, you need to install CAPKI on all computers in which any of the mentioned components run.

Important! CAPKI is not supported in the Automic Automation Kubernetes Edition but you can use the ServiceManager without CAPKI to start your agents.

More information:

TLS/SSL and the REST API

The AE REST API supports both HTTP and HTTPS (recommended). HTTP is used by default. You can enable HTTPS using the sslEnabled parameter in the INI file of the Automation Engine (ucsrv.ini).

When you enable TLS/SSL you have to make sure that the certificate you use for the Java communication process (JCP) is also configured so that the REST API can reach the REST process.

More information:

TLS/SSL and the Java Work Process

If you want, you can use TSL/SSL certificates for the LDAP connection. To do so, the required certificates must be available to the Java work process (JWP).

More information:

TLS/SSL and Analytics

Analytics uses TLS/SSL to secure the communication of the Analytics Backend with the Automation Engine and the UI plug-in, as well as the communication of the Event Engine and, optionally, the Rule Engine.

More information:

TLS/SSL and the Proxy

Besides the communication between the Automation Engine and the Proxy Client, the following Proxy connections also use TLS/SSL:

The communication between the Proxy Client and Proxy Server
The communication between the Proxy Server and the TLS/SSL Agents

More information:

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: