Certificate Discovery

Digital certificates have a limited validity period. In most cases they are rendered useless once they expire. As a consequence, services that rely upon those certificates do not function properly, or go completely out of service. Several similar incidents have been observed in the past. Therefore, a reliable mechanism to locate and manage such certificates is necessary to avoid such situations. Additionally, keeping track of all certificates in a system and/or infrastructure is beneficial, because it allows to locate mis-issued certificates. It is also possible to enforce policies in an easier manner, tied to cryptographic mechanisms or other aspects of certificates.

The MTG Certificate Lifecycle Manager (MTG CLM) consists of two components, amongst others. The server and the clients. The server is the standard MTG CLM application which is the central component of the MTG ERS system. For an illustration of the graphical interface of this component, see Figure 1. This component also provides a REST-API that can be securely accessed by authenticated and authorised clients.

The clients are the so-called ERS CLI (Command Line Interface) clients. A CLI client is a program that consumes the REST-API of CLM. This CLI-client is able to log in to CLM and request a certificate. Additionally, it can scan certain ports or port ranges of several other systems located near its network. This can be configured on the command-line interface of the system where an ers client is installed. The installation of an ers client uses typical mechanisms of modern operating systems like rpm or debian packages, or exe files and contains all its dependencies without depending on other resources. Examples to configure the servers, IPs, and ports to scan can be found below:

Consecutive calls of ers discover lead to adding additional servers or re-configuring the ports to scan. The standard ports where the CLI client scans are shown below:

To scan the configured servers and ports, execute:

In most cases the command ers scan is placed in a crontab statement with the desired execution time.

When the ers client scans, it tries to establish a TLS connection to the specified server and ports. If it succeeds into establishing a TLS connection it downloads the certificates of the server and pushes them to the CLM component along with some metadata, via a call to the REST-API. The CLM verifies the identity of the client and stores the certificates and metadata into its database. Below is a simplified UML sequence diagram of the calls, responsibilities, and involved systems:

Imported certificates and metadata are administered by the application. Examples of metadata is the URL and port where the certificates have been discovered. Typical administration tasks are:

All CLI clients can be seen and managed in the GUI of CLM.

The CLI client can scan the local filesystems on which it is installed, to locate files with known formats like PEM, DER, PKCS12, JKS, or JCEKS. When such files are discovered, these files and/or location and metadata are pushed to CLM. The CLM then, administers this information.