Configuring Server Certificate Validation Settings

You can configure server certificate validation settings to make certificate validation more secure or less secure. These settings are used for validating the server certificate that is passed from a remote event broker to the local event broker during a TLS/SSL handshake.

Certificate validation settings can be specified for Message VPN bridges and replication Config-Sync bridges.

You can make the following certificate validation configurations:

When you make a change to the server certificate validation settings for Message VPN bridges, the PubSub+ broker automatically disconnects and then reconnects all TLS-enabled bridges in the Message VPN to enable the change.

For information on setting a client certificate for Message VPN bridges, refer to Configuring Client Certificate Authentication.

Enabling Server Name Validation

You can enable or disable the TLS authentication mechanism to verify the name used to connect to the remote broker. If enabled, the Server Name Indication (SNI) extension is sent on outgoing TLS connections and the server name used for that connection is verified against the server names in the Subject Alternative Name (SAN) extension in the certificate returned from the remote broker.

This parameter is disabled for existing VPNs on brokers that have been upgraded from versions prior to 9.6; otherwise it is enabled by default.

  • Message VPN Bridges

    To enable the validation of server names for Message VPN bridges, enter the following commands:

    solace(configure)# message-vpn <vpn-name>

    solace(configure/message-vpn)# bridging ssl server-certificate-validation

    solace(...ing/ssl/server-certificate-validation)# validate-server-name

  • Replication Config-Sync Bridges

    To enable the validation of server names for replication Config-Sync bridges, enter the following commands:

    solace(configure)# replication

    solace(configure/replication)# config-sync bridge ssl-server-certificate-validation

    solace(...dge/ssl-server-certificate-validation)# validate-server-name

When validate-server-name is enabled, the enforce-trusted-common-name parameter is ignored (the broker behaves as if enforce-trusted-common-name is false regardless of its actual value).

The no version of these commands, no validate-server-name, disables the validation of server names.

Configuring Maximum Certificate Chain Depths

The depth of a certificate chain is the number of signing CA certificates that are present in the chain back to a trusted self-signed root CA certificate. Setting a maximum certificate chain depth means that bridge connections will reject any certificates whose depth is higher than the maximum limit.

  • Message VPN Bridges

    To configure the maximum certificate chain depth for Message VPN bridges, enter the following commands:

    solace(configure)# message-vpn <vpn-name>
    solace(configure/message-vpn)# bridging ssl server-certificate-validation
    solace(...ing/ssl/server-certificate-validation)# max-certificate-chain-depth <max-depth>

    Where:

    <max-depth> is a number from 0 to 8 specifying the maximum number of signing CA certificates that may be present in the certificate chain. The default value is 3.

  • Replication Config-Sync Bridges

    To configure the maximum certificate chain depth for replication Config-Sync bridges, enter the following commands:

    solace(configure)# replication
    solace(configure/replication)# config-sync bridge ssl-server-certificate-validation
    solace(...dge/ssl-server-certificate-validation)# max-certificate-chain-depth <max-depth>

    Where:

    <max-depth> is a number from 0 to 8 specifying the maximum number of signing CA certificates that may be present in the certificate chain. The default value is 3.

The no version of these commands, no max-certificate-chain-depth, resets this parameter to its default value.

Enabling Certificate Date Validation

Certificates may specify "not before" and "not after" dates to provide a time range for which they will be valid. This setting will enable or disable the validation of these dates. If this check is disabled, the bridge will accept a certificate even if the valid date range provided in the certificate is not fulfilled.

By default, validation of certificate dates is enabled.

  • Message VPN Bridges

    To enable validation of certificate dates for Message VPN bridges, enter the following commands:

    solace(configure)# message-vpn <vpn-name>
    solace(configure/message-vpn)# bridging ssl server-certificate-validation
    solace(...ing/ssl/server-certificate-validation)# validate-certificate-date

  • Replication Config-Sync Bridges

    To enable validation of certificate dates for replication Config-Sync bridges, enter the following commands:

    solace(configure)# replication
    solace(configure/replication)# config-sync bridge ssl-server-certificate-validation
    solace(...dge/ssl-server-certificate-validation)# validate-certificate-date

The no version of these commands, no validate-certificate-date, disables validation of the certificate dates.

Enforcing Trusted Common Names

In release 9.7.0 and later, the enforce-trusted-common-name command has been deprecated and replaced with the validate-server-name command. The command has been hidden for backward compatibility and no longer appears in the help or CLI Command Reference. For more information about the validate-server-name command, refer to Enabling Server Name Validation.

If you have upgraded from release 9.6.0 or earlier and want to switch from trusted common name enforcement to server name validation, first verify that the hostname or IP address used in configuration for the remote server matches a hostname or IP address in the certificate returned from that server during the TLS handshake. If the hostname matches, enable server name validation. If the hostname doesn’t already match, you must update the hostname appropriately first. Once server name validation is enabled, trusted common name enforcement and the trusted common name list are ignored.

You can configure a list of trusted common names that a connecting bridge or event broker expects to be returned in a server certificate from a remote bridge. You may choose not to enforce this list of common names, in which case the connecting bridge or event broker will consider any server certificate that it receives.

  • Message VPN Bridges

    To enable the checking of common names on Message VPN bridges, enter the following commands:

    solace(configure)# message-vpn <vpn-name>

    solace(configure/message-vpn)# bridging ssl server-certificate-validation

    solace(...ing/ssl/server-certificate-validation)# enforce-trusted-common-name

  • Replication Config-Sync Bridges

    To enable the checking of common names on Replication Config-Sync bridges, enter the following commands:

    solace(configure)# replication

    solace(configure/replication)# config-sync bridge ssl-server-certificate-validation

    solace(...dge/ssl-server-certificate-validation)# enforce-trusted-common-name

The no version of these commands, no enforce-trusted-common-name, disables the checking of trusted common names.

If this option is enabled but a list of common names has not been configured for the bridge, the connection will not be permitted.