Certificate Authorities

This section provides basic information that will help you configure certificate authorities and manage certificate revocation checking for client authentication.

Solace PubSub+ event brokers allow clients to authenticate over TLS by presenting a valid client certificate. The event broker authenticates the client certificate by constructing a full certificate chain (from the client certificate to intermediate CAs to a configured root CA). The intermediate CAs in this chain can be provided by the client, or configured in the event broker. The root CA must be configured on the event broker.

Configuring Certificate Authorities

For Solace PubSub+ appliances using version 8.2.0+ and Solace PubSub+ software event brokers using version 8.7.0+, CA certificates must be configured to validate incoming certificates for all SSL connections.

The certificate files for a CA can only contain a single certificate. There are a couple of other considerations depending on whether you're also using SSL/TLS authentication and / or revocation checking:

  • SSL/TLS Authentication
  • At a minimum you must configure the root CA on the broker.

  • Certificate Authority Revocation Checking
  • The root CA and all the intermediate CAs that complete the chain must be configured on the broker.

Here are the Solace CLI commands for CA creation and configuration.

  1. To create a CA, enter the following commands:

    solace(configure)# authentication
    solace(configure/authentication)# create certificate-authority <ca-name>

    To configure an existing CA, enter the following command:

    solace(configure/authentication)# certificate-authority <ca-name>

  2. Each certificate in the chain must be configured for authentication. To configure a CA certificate, enter the following command:

    solace(configure/authentication/certificate-authority)# certificate file <ca-certificate>

Where:

ca-name is the name of the certificate authority. You can use a maximum of 64 characters for a ca-name. Acceptable characters are alpha-numeric characters, period (.), hyphen (-), and under score (_).

ca-certificate is the filename of the CA certificate. This file must be located in the /certs directory on the event broker. Once the certificate is in the certs directory, you can individually add certificates to the list of trusted CA certificates. The maximum number of trusted CA certificates that may be loaded is 64.

The no version of the certificate command, no certificate, removes the CA from the event broker.

  • CA certificates are HA Config-Sync'ed, but not Replication Config-Sync'ed.
  • Once a CA certificate is configured, a copy of it is saved internally. The file in the /certs directory is no longer required.

Configuring Certificate Revocation Checking

An event broker can check the revocation status of the certificate that clients use when attempting to authenticate. You can configure certificate revocation checking on a per-event broker basis. However, you can also configure overrides on a per-Message VPN basis to ignore the results of the revocation check, and to allow authentication of certificates with unknown revocation status.

You can configure event brokers to check the revocation status of client certificates using one of the following methods:

  • Certificate Revocation List (CRL)
  • Online Certificate Status Protocol (OCSP)
  • OCSP-CRL (Combination of both)

For more information, see Certificate Revocation Checking Methods.

To enable certificate revocation checking, enter the following command:

solace(configure/authentication)# client-certificate-revocation-checking [none | ocsp | crl | ocsp-crl]

Where:

none (default) specifies to not check the revocation status of certificates during validation and all the certificates are considered valid.

ocsp specifies to use OCSP to verify the revocation status of the certificates during validation.

crl specifies to use CRL to verify the revocation status of the certificates during validation.

ocsp-crl specifies to use OCSP first to verify the revocation status of the certificates, if OCSP fails to return an unambiguous result, then CRL is used to check the revocation status of the certificates.

For a step-by-step procedure to configure OCSP, CRL, or OCSP-CRL certificate revocation checking, see the following.