Preparing TLS/SSL Certificates

The communication between the Automation Engine, the Automic Web Interface, the Java API, and the Proxy Client as well as between the Automation Engine, the TLS/SSL Agents (Java, Windows, UNIX Agents) and the TLS Gateway 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). These server processes 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! Check Broadcom's Enterprise 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:

Considerations Before Installing Automic Automation Version 21

Make sure you consider the following issues before upgrading to or installing Automic Automation version 21:

  • 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.

Certificates Overview

A public key certificate contains information such as name, hostname/domain name/IP address, validity period, and location to be used to identify the owner (server). It also includes the public key that the client uses to verify the server. Using a digital signature to sign the certificate, for example by a public or commercial Certificate Authority (CA), ensures not only that the certificate is valid but also that it can be trusted by all clients that trust that CA.

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 clients (AWI, Agents, and so on).

Types of Certificates

There are three types of certificates available to secure the communication:

  • Self-signed certificates

    Using self-signed certificates gives you flexibility and does not require you to be a TLS/SSL expert. However, renewing and distributing the certificates required is your responsibility.

  • Certificates signed by an internal Certificate Authority (CA)

    Creating your own internal Certificate Authority (CA) to sign your certificates is beneficial if you are working in a testing environment or using applications that are not Internet facing. In this case you eliminate the need to turn to third-party vendors.

  • Certificates signed by a public Certificate Authority (CA)

    Using certificates signed by a public Certificate Authority (CA), such as IdenTrust, DigiCert, Let’s Encrypt, GlobalSign, and so on, is recommended if you are working with production environments and applications that are Internet facing. These registered CAs are authorized to issue end certificates that are trusted by browsers and other applications using TLS/SSL to secure connections, thus reducing the effort of managing certificates.

Creating and Using TLS/SSL Certificates - AE, Agents and AWI Connections

In this section you can find an overview of how to create and use TLS/SSL certificates signed by either an internal or a public Certificate Authority (CA) or self-signed ones. The difference among them lies in how the certificates are created:

  • Self-signed certificates

    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.

    Java Keytool example

    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"

  • Certificates signed by an internal CA

    You can create an internal CA using tools such as OpenSSL. In this case, you can also decide if you want to create multiple layers of CAs or an internal CA root certificate to sign the end certificate of the Automic server.

    To do so, you have to create the required files: the private key and the self-signed root certificate.

    The private key must be stored in a secure location and should be password protected. This password is required when creating the root certificate. Since the end certificate(s) used for the server can have a shorter lifespan, the validity period of the CA root certificate can be longer.

    Example

    $ openssl req -x509 -new -key automicCA.key -sha256 -days 700 -out automicCA.crt

    You require a Certificate Signing Request (CSR) to sign other certificates with this CA. To do so, create a private key for the Automic server.

    If your company already has an internal CA used to create end certificates for other applications you can skip this step and use that internal CA.

  • Certificates signed by a public CA

    In this case, you have to request the public CA of your choice to provide you with the certificates you need. There are multiple ways of getting these certificates. The relevant companies provide specific tools or APIs to do so. CA root certificates are usually used only to sign intermediate certificates that can then verify the identities of end domains.

    If your company already uses certificates signed by a public CA for other applications you can skip this step.

Regardless of which type of certificates you use, once you have your certificates in place, you have to deploy the TLS/SSL keystore, and configure the Automation Engine, the Automic Web Interface, the TLS/SSL Agents (Java, Windows and UNIX Agents) and the TLS Gateway to work with your certificates.

  • Deploying 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 keystore file to the target server before starting the Automation Engine and testing your connections.

  • Configuring AWI

    If you are using self-signed certificates, you have to 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 Agents and/or TLS Gateway

    If you are using self-signed certificates, you have to 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.

When you use certificates signed by a CA, you do not have to 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.

For more information about the different certificate types and for detailed instructions on how to create and use them, see What Kind of Certificates Should I Use for Automic Automation v21.

High Availability, Multiple Network Cards or JCPs on Multiple Servers

Every IP Address and server/hostname used in Automic Automation must exist in the certificate. Therefore, multiple network cards, different internal and external addresses, DNS aliases or numerous JCPs across different servers, all require you to define Subject Alternative Names (SAN).

Note: If you define a Subject Alternative Name (SAN), you must repeat the Common Name (CN) in the SAN list because the Common Name is ignored when Subject Alternative Names are present.

To create a CSR you have to specify the Common Name (CN) for the server certificate and it must match the hostname/domain/address that the agents use to connect to the server.

Education

The Enterprise Software Academy provides a wide range of free online trainings. If you have not already done so, register at Enterprise Software Academy to start profiting from our education offer.

The following course(s) are associated with this topic:

  • Automic Automation TLS and Certificates

  • Automic Automation TLS Gateway

For more information, see Free Online Courses

See also:

Upgrade Installation