CAPKI - Securing the ServiceManager

The CAPKI libraries provide features that are required for information security services, such as the TLS implementation, and is required for the secure communication of the ServiceManager. CAPKI is available for Windows and all Unix platforms supported by the Automation Engine and can be downloaded from https://downloads.automic.com/.

This page includes the following:

Overview

The Automation Engine uses CAPKI to establish TLS 1.2 based secure connections between the ServiceManager and its clients, the ServiceManager Dialog Program, the ServiceManager Command Line and the Automation Engine itself. You have to install CAPKI on all computers on which server processes, the ServiceManager, or any of its clients run.

More information:

Recommendations

It is recommended to carry out the following upgrade steps in the order they are listed here:

  1. Install CAPKI on all computers on which server processes, the ServiceManager, and any of its clients run.

    Important! It is recommended to roll out CAPKI before installing or upgrading components of the Automation Engine that require CAPKI. If, for any reason, you have to install CAPKI after installing or upgrading these components, you must restart the components for CAPKI to take effect.

  2. Upgrade the Automation Engine and all its components either manually or by using the MDU and the Centralized Agent Upgrade (CAU).

  3. In the UC_SYSTEM_SETTNGS variable, set the SMGR_SUPPORT_LEGACY_SECURITY parameter to N.

    Important! Once this parameter is set to N, the Automation Engine no longer supports communication with legacy ServiceManagers.

    More information:

Following this order guarantees a seamless functioning during the upgrade process. The new ServiceManager Dialog and CLI components, as well as the communication processes of the Automation Engine still can communicate with a legacy ServiceManager but not the other way around. Thus the importance of upgrading the Automation Engine, the ServiceManager Dialog Program and the CLI Program first and the ServiceManagers at the end.

Compatibility

A ServiceManager that supports CAPKI only allows connections of clients (Automation Engine, ServiceManager Dialog Program, and ServiceManager Command Line) that also support CAPKI. However, the ServiceManager Dialog Program and the ServiceManager Command Line can contact legacy ServiceManagers that do not support CAPKI.

Note: The new ServiceManager Dialog Program has an indicator which visualizes whether it is connected to a secure or a legacy (insecure) ServiceManager.

You can configure the compatibility of the Automation Engine using the SMGR_SUPPORT_LEGACY_SECURITY parameter in the UC_SYSTEM SETTINGS variable.

Configuring the CAPKI Environment (UNIX)

To configure the CAPKI environment correctly, you must have the CASHCOMP environment variable pointing to the parent directory of the CAPKI installation directory. If the setting env=all is set during the installation, the CASHCOMP environment variable is added automatically to /etc/profile.CA which is sourced by /etc/profile. If you install the automicsm service daemon start script for the ServiceManager, make sure that the CASHCOMP environment variable is set accordingly in the script.

Example

export CASHCOMP=/opt/CA/SharedComponents

Installing CAPKI

The CAPKI libraries are available for Windows and UNIX platforms supported by the Automation Engine and can be downloaded from https://downloads.automic.com/.

You can install CAPKI on each computer for various applications and each installation has to be registered with a freely defined name (CallerID). Only the first CAPKI installation installs libraries in the system. All subsequent ones merely register additional applications for use and do not modify existing CAPKI installations. Conversely, you can only uninstall CAPKI (remove the libraries from your system) if no application uses CAPKI anymore. If you try to uninstall CAPKI and there are other applications still using it, the respective application gets unregistered only.

CAPKI keeps and manages a list of the applications that are installed on the system and their respective CAPKI versions. This list must not be modified manually but can be used as a source of information, for example, if you want to uninstall an application and no longer have the relevant CallerID. You can find the list in the following locations:

Important! Windows installations require administrator privileges. It is recommended to perform UNIX installations with root privileges. However, you can also carry out a UNIX installation under a specific user only. In this case, only a subset of the parameters and settings apply.

To install CAPKI, use the setup.exe (Windows) or setup (UNIX) installer respectively. They support the following parameters:

You can also apply the following settings:

Important! Make sure the installation user has the necessary permissions for the installation directory.

Examples

UNIX (root)

Important! It is recommended to carry out UNIX installations with root privileges.

When you install CAPKI in UNIX as root, the following parameters and settings are supported:

./setup install caller=automic veryverbose env=all

Installs CAPKI and sets environment variables for all users (/etc/profile).

./setup install caller=automic veryverbose env=none

Installs CAPKI but it does not set any environment variables.

./setup remove caller=automic veryverbose

Uninstalls CAPKI.

./setup discover

Searches for CAPKI installations in the system.

UNIX (non-root)

Important! It is recommended to carry out UNIX installations with root privileges. However, you can also carry out a UNIX installation for the current user only.

When you install CAPKI in UNIX without root privileges, only the following parameters and settings are supported:

./setup install caller=automic veryverbose env=user

Installs CAPKI locally and sets the environment variables for the current user only ($HOME/.profile)

./setup remove caller=automic veryverbose env=user

Uninstalls CAPKI but it does not delete the environment variables from $HOME/.profile

./setup discover

Searches for CAPKI installations in the system (root), not installations in the current user's $HOME directory.

Windows

Important! Windows installations require administrator privileges.

setup.exe install caller=automic veryverbose

Installs CAPKI.

setup.exe remove caller=automic veryverbose

Uninstalls CAPKI.

setup.exe discover

Searches for CAPKI installations in the system.

Setup Return Codes

Possible return codes are:

(*) CAPKI may not be available for use until the reboot has been performed.

Logging and Diagnostics

The installation log file capki_install.log is generated upon installation and contains error, warning, and information messages. You can find the log file in the temp directory:

Notes:

Configuring the Automation Engine and the ServiceManager

Certificate Handling

The ServiceManager uses cryptographic keys and a certificate to establish a TLS-secured connection. At startup, the Automation Engine and the ServiceManager automatically create their own self-signed certificates and key files and write the path information in the [CAPKI] section of their configuration (.INI) files. You must use the .pem format for own certificates.

For example, in Windows:

[CAPKI]

certificate=C:\Automic\Automation.Platform\AutomationEngine\bin\ucsrv_certificate.pem

key=C:\Automic\Automation.Platform\AutomationEngine\bin\ucsrv_key.pem

;chain=

cert_trusted_folder=.\trusted

Important! It is strongly recommended to replace the certificates generated automatically, with certificates issued by a certification authority (CA). You need define the path to your own certificate and key file in the corresponding configuration (.INI) file.

Certificate Validation

The Automation Engine, ServiceManager Service, ServiceManager Dialog Program and ServiceManager CLI do not validate any certificate by default. This means that, by default, all certificates are trusted. The ServiceManager, ServiceManager Dialog and CLI can handle their own certificate stores, which contain all trusted certificates.

To enable certificate validation for the components mentioned above you need to create a folder which contains all certificates the component should consider as trusted. The default path for this folder is defined in the component's INI file: cert_trusted_folder=.\trusted.

Example

Automation Engine A has a certificate in its trust store while Automation Engine B does not. If both try to start an agent from the Administration perspective, Automation Engine A is successful, while Automation Engine B gets a message stating that the connection to the ServiceManager was not successful due to a certificate validation error.

Important! If the ServiceManager and one of its clients (such as the CLI Program) are located in the same .\bin folder, you need to separate the two trusted folders. To do so, create a second folder and modify the parameter in the ServiceManager's INI file. For example, cert_trusted_folder=.\sm_trusted.

If at least one certificate (.pem format) is stored in the defined folder, the component verifies the trust of certificate when establishing a connection. A certificate is trusted if the certificate itself or the Certification Authority (CA) that signed the certificate is present. Otherwise, the certificate is not considered as trusted and the connection is terminated.

Certificate Renewal

Certificates only need to be renewed if they have expired or are about to expire and you are using a trust store. In this case, the ServiceManager Dialog displays the error message Certificate Validation Error: Trusted connection could not be established.

An existing certificate can be renewed automatically (self-signed certificates) or you can provide your own certificate. In both cases, the new certificate must be added to the trust store of all components that will connect to the one with the new certificate:

Trust Store Update

For security reasons, new certificates are not distributed automatically. Since every component needs the certificate of the components to which it connects to, you have to copy the new certificates to the trust store of all those components. The distribution process can be more efficient if the certificates you supply are signed by a certification authority (CA). In this case, only the signing CA must be added to the trust store and all certificates signed by the authority are trusted automatically.