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:
- Enabling Server Name Validation
- Configuring Maximum Certificate Chain Depths
- Enabling Certificate Date Validation
- Enforcing Trusted Common Names
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.