Certificate management

When using Remote Control to facilitate remote control sessions across the internet, you can use certificates to address the authentication and verification required for ensuring secure connections between brokers and endpoints.

A separate certificate is required for each broker that is added to the Remote Control infrastructure. This certificate needs to be trusted by the components that can connect to the broker, that is other brokers, controllers and targets and this is achieved by having signing certificates that are used to sign the broker certificates. These certificates can be self-signed or part of a chain coming from a valid internal or external Certificate Authority (CA). The signing certificates are held in a trust store on the Remote Control server and are used to verify the broker certificates.

The broker supports two key store formats.
This key store format is supported by the IBM Key Management tool (ikeyman), which ships as part of Remote Control in the embedded Websphere Application Server (WAS) or standalone WAS.
PEM files can be generated with the OpenSSL command line tool or other third party tools. The OpenSSL command-line tool is not shipped with Remote Control.
The PEM file needs to contain the following items, in the order listed below.
  1. Broker's certificate
  2. Any intermediate certificates, if required
  3. Root certificate
  4. Broker's private key
Use a text editor or the UNIX cat command to combine all the items in a single file.
Remote Control can use multiple types of Public Key Infrastructure ( PKI)
  • A commercial Certificate Authority ( CA)
  • An internal CA
  • Self signed certificates
There is no difference between using a commercial CA or an internal CA and it is possible to mix the two kinds. For example, you can run the Remote Control server with a self-signed certificate while running all brokers with CA-signed certificates.
Remote Control provides two levels of certificate validation, strict certificate validation and non-strict certification validation.
Non-strict certificate validation
  • Non-strict certificate validation performs the following checks against the certificate
    • The identity of the certificate matches the hostname of the broker that you are trying to connect to.
    • The certificate is within its validity period.
    In non-strict mode, the client does not need a trust store to perform the validation.
    Note: This type of certificate validation is strongly discouraged for production usage for remote control sessions over the internet, it is only intended for demo and test environments.
Strict certificate validation
  • Strict certificate validation performs one additional check. This additional check requires that the client has a trust store that contains all the root certificates required to validate the certificate chain.
The certificate chains to a valid root CA, whose certificate is in the client's trust store