TLS / SSL Encryption
By default, clients use plain text over TCP to exchange data with Solace PubSub+ event brokers, and the data that is exchanged is not compressed.
However, clients can use Transport Layer Security (TLS)/ Secure Sockets Layer (SSL)‑encrypted connections to an event broker. This allows an exchange of uncompressed Solace Message Format (SMF) data or Solace Element Management Protocol (SEMP) data with the event broker using TLS/SSL over single TCP connections instead of plain text over TCP.
Using TLS/SSL-encrypted connections to an event broker offers:
- Confidentiality—messages can only be received by the intended recipient
- Message integrity—messages cannot be modified after being sent
- Server authentication—the connected application is able to verify the server it is communicating with is the server it believes it is
- Client authentication—optional client certificates can be used as a form of client authentication (for more information, see Client Authentication)
The following types of applications can establish TLS/SSL-encrypted connections to an event broker:
- Client applications that publish and/or receive messages.
- Network management applications that manage and monitor the event broker through SEMP requests and replies.
- If the network management application uses SEMP Request Over Message Bus service, which uses a Solace messaging API to establish a client connection through a session, SEMP requests and replies can be sent over the event broker message bus. A secure session can be established in the same manner as that used by a client application.
- If the network management application uses SEMP Request over HTTP service, a TCP connection to a port on the event broker allows the application to send SEMP requests wrapped in HTTP to a management interface on the event broker and receive replies to them. For SEMP Request over HTTP service, a secure connection can be created when a server certificate is set on the event broker, a TLS/SSL-secure port is specified (443 by default), and an HTTPS URL scheme is used.
By default, when a client application connects to an event broker and creates a session, that session is unsecured. However, a client application can optionally create a secure session that requires a trusted server certificate to establish a TLS/SSL-encrypted client connection to an event broker.
Client applications can use the Solace messaging APIs to establish secure connections to an event broker.
SSL encryption can also be used on Message VPN bridges and bridges established by the Message VPN replication and replication Config-Sync facilities. Using encryption on bridge links helps to ensure that communications between event brokers over bridges are secure.
Because encrypting and decrypting data requires processing power, enabling TLS/SSL encryption may cause a reduction in performance.
Cipher Suites
The following cryptographic algorithms are used throughout the life of a TLS/SSL‑encrypted connection:
- Key establishment—This algorithm is used to exchange or agree on the symmetric keys to be used for encrypting and decrypting the data payload during the session. Examples: RSA, Diffie-Hellman (DH), Ephemeral Diffie-Hellman (DHE), and Elliptic Curve Diffie-Hellman (ECDH).
- Authentication—This algorithm is the digital signature used by the certificates passed between the client application and server. Examples: RSA and Digital Signature Standard (DSS).
- Encryption—This algorithm encrypts and decrypts payload passed on the secure session. Examples: RC4, 3DES CBC, and Advanced Encryption Standard (AES).
- Digest—This algorithm is used to maintain message integrity. Tampering with the message would render the digest invalid. Examples: SHA1, MD5.
The combination of these four cryptographic algorithms is known as a cipher suite.
For the full list of cipher suites event brokers support, refer to Supported Cipher Suites.
Cipher Suites for Inbound Connections
Event brokers maintain a separate cipher suite list for each of the following inbound TLS connection types:
- Network management applications using SEMP to manage the event broker (management connections)
- Client applications connecting to the event broker to publish or receive messages (message backbone connections)
Cipher suites for all inbound management and message backbone connections are selected according to the priority clients associate with each cipher suite.
Cipher Suites for Outbound Connections
Event brokers maintain a separate prioritized cipher suite list for each of the following outbound TLS connection types:
- Message VPN and bridge connections
- Replication bridge connections
- Config-sync bridge connections
- Multi-node routing links
In addition, the event broker uses the same cipher suite list for outbound LDAP connections that it uses for inbound management connections.
Cipher suites for all outbound connections (including LDAP connections) are selected according to the priority configured in each corresponding cipher suite list.
Ciphers for SSH Connections
Event brokers maintain a list of ciphers for all SSH, SCP, and SFTP connections. For purposes of encrypted connections, the cipher list has a similar function to a cipher suite list; however, key establishment, authentication, and digest algorithms are not used. For the full list of ciphers event brokers support, refer to Supported Ciphers.
Ciphers for all SSH connections are selected according to the priority clients associate with each cipher.
Supported Cipher Suites
The following table shows the full list of cipher suites event brokers support for inbound and outbound connections.
Supported Cipher Suites (strongest to weakest)
| OpenSSL name | IANA name | Default Security Policy | FIPS Compliant Security Policy |
|---|---|---|---|
|
ECDHE-RSA-AES256-GCM-SHA384 |
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 |
Supported |
Supported |
|
ECDHE-RSA-AES256-SHA384 |
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 |
Supported |
Supported |
|
ECDHE-RSA-AES256-SHA |
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA |
Supported |
Supported |
|
AES256-GCM-SHA384 |
TLS_AES_256_GCM_SHA384 |
Supported |
Not Supported |
|
AES256-SHA256 |
TLS_RSA_WITH_AES_256_CBC_SHA256 |
Supported |
Not Supported |
|
AES256-SHA |
TLS_RSA_WITH_AES_256_CBC_SHA |
Supported |
Not Supported |
|
ECDHE-RSA-DES-CBC3-SHA |
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA |
Not Supported |
Not Supported |
|
DES-CBC3-SHA |
SSL_RSA_WITH_3DES_EDE_CBC_SHA |
Not Supported |
Not Supported |
|
ECDHE-RSA-AES128-GCM-SHA256 |
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 |
Supported |
Supported |
|
ECDHE-RSA-AES128-SHA256 |
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 |
Supported |
Supported |
|
ECDHE-RSA-AES128-SHA |
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA |
Supported |
Supported |
|
AES128-GCM-SHA256 |
TLS_RSA_WITH_AES_128_GCM_SHA256 |
Supported |
Not Supported |
|
AES128-SHA256 |
TLS_RSA_WITH_AES_128_CBC_SHA256 |
Supported |
Not Supported |
|
AES128-SHA |
TLS_RSA_WITH_AES_128_CBC_SHA |
Supported |
Not Supported |
When using TLS 1.2, certificate keys must be at least 1024 bits in length. When using keys shorter than 1024 bits, you may receive a “digest too big for RSA key” error.
Supported Ciphers
The following table shows the full list of ciphers event brokers support for SSH connections.
| Ciphers |
Default Security Policy | FIPS Compliant Security Policy |
|---|---|---|
|
aes128-ctr |
Supported |
Supported |
|
aes192-ctr |
Supported |
Supported |
|
aes256-ctr |
Supported |
Supported |
|
aes128-gcm@openssh.com |
Supported |
Not Supported |
|
aes256-gcm@openssh.com |
Supported |
Not Supported |
Configuring Cipher and Cipher Suite Lists
You can configure each default cipher and cipher suite list to avoid using specified ciphers or cipher suites, or you can reorder each list to change the priority associated with a given cipher or cipher suite.
To configure cipher suite lists for inbound connections, refer to Configuring Cipher Suites for Inbound Connections.
To configure cipher suite lists for outbound connections, refer to the following sections:
- For Message VPN and bridge connections, refer to Configuring VPN Bridges.
- For replication bridge and replication Config-Sync connections, refer to Configuring System-Level Replication Settings.
- For LDAP connections, refer to Configuring Cipher Suites for Management Connections. The event broker uses the same cipher suite list for LDAP and management connections.
- For multi-node routing links, refer to Multi-Node Routing.
To configure ciphers for SSH connections, refer to Configuring Ciphers for SSH Connections.
Supported Signature Algorithms
An event broker can validate a certificate chain if all certificates in the chain are signed with one of the following signature algorithms:
| Signature Algorithm | Default Security Policy | FIPS Compliant Security Policy |
|---|---|---|
|
md2withRSAEncryption md4withRSAEncryption md5withRSAEncryption |
Supported |
Not Supported |
|
shawithRSAEncryption sha1withRSAEncryption sha1withDSAEncryption |
Supported |
Not Supported |
|
sha224withRSAEncryption |
Supported |
Supported (key must be greater than or equal to 2048 bits) |
|
sha224withDSAEncryption |
Supported |
Not Supported |
|
sha256withRSAEncryption |
Supported |
Supported (key must be greater than or equal to 2048 bits) |
|
sha256withDSAEncryption |
Supported |
Not Supported |
|
sha384withRSAEncryption |
Supported |
Supported (key must be greater than or equal to 2048 bits) |
|
sha512withRSAEncryption |
Supported |
Supported (key must be greater than or equal to 2048 bits) |
Server Certificates Authentication Process
The following process is used when a client or management application connects to an event broker and requires certificate validation to establish a secure connection.
Certificate Validation Process Using TLS/SSL
- The client or management application connects to the event broker’s TLS/SSL listening port.
- The event broker responds to the client or management application with its server certificate.
- The client or management application verifies that the server certificate is valid, is named as expected, and that it was issued by a trusted root certificate.
- If the validation succeeds, the client or management application will respond and continue to complete the handshake.
If an Active/Active redundancy configuration is used, each event broker in the redundant pair should have its own server certificate with its own common name. If an Active/Standby redundancy configuration is used, the two mates can share a server certificate that uses the name of the primary event broker as the common name.
Certificate Authorities
Prior to version 9.8.0, PubSub+ event brokers used a single certificate authority (CA) list for both incoming and outgoing TLS connections as well as CRLs and OCSP. This list was not pre-populated, meaning you needed to configure the list and the corresponding CA certificates before enabling TLS encryption on incoming or outgoing connections.
In version 9.8.0+ PubSub+ event brokers use three lists of CAs:
- The standard domain validation list— A pre-populated list of standard, trusted domain validation root certificates used to verify the server name for all outgoing TLS connections, including TLS connections for OCSP requests and to obtain CRLs. Event brokers use a combination of this list and the domain validation list during domain validation. This list cannot be modified, however, you can disable it and use only the domain validation list.
- The domain validation list— Used to verify the server name for all outgoing TLS connections, including TLS connections for OCSP requests and to obtain CRLs. You can modify the CAs in this list to suit your deployment.
- The client authentication list— Used to validate client certificates on incoming TLS connections, CRLs, and OCSP responses.
To configure CA lists, refer to Configuring Certificate Authorities.
Certificate Revocation Checking
Checking the revocation status of client certificates is supported for Solace PubSub+ appliances as of version 8.2.0, and is supported by the Solace PubSub+ software event brokers as of version 8.7.0. Before these releases, while validating the client certificates, the event broker did not check the revocation status of the certificates.
An event broker can check the revocation status of the certificate that clients use when attempting to authenticate. The certificate revocation is configurable on a per-event broker basis with override options per-Message VPN. You can configure Message VPN overrides to ignore the results of the revocation check or to allow authentication of certificates with unknown revocation status. For more information, see Configuring Message VPN Overrides.
The revocation status of a certificate chain can have one of the following states:
- Valid—All certificates in the chain have been checked for revocation and for whether they are valid.
- Unknown—One or more certificate in the chain cannot be verified. It is, however, possible for OCSP to return unknown if the certificate is not revoked and not known to the CA.
- Revoked—One or more certificate in the chain have been revoked.
With the certificate revocation checking enabled, there are several potential conditions that may lead to the status of a certificate chain to be unknown. The information below describe those conditions when CRL, OCSP, or OCSP-CRL certificate revocation check is enabled:
-
CRL—If a cached copy of the CRL is not available or if the CRL has expired.
-
OCSP—If the event broker does not receive a response from the OCSP responder within the default timeout, or if the response signer is not recognized as a genuine responder. The responder is required to sign the OCSP responder with certificates issued to specific common names and must contain appropriate OCSP flags.
-
OCSP-CRL—When using OCSP-CRL, following conditions may lead to the revocation status of a certificate to be unknown:
-
The OCSP response signer is not recognized as a genuine responder.
-
The event broker does not receive a response from the OCSP responder within the default timeout and a cached copy of the CRL is not available, or if the CRL has expired.
-
To learn about CRL, OCSP, OCSP-CRL certficate revocation checking, see Certificate Revocation Checking Methods
Clients that Support Certificate Revocation Checking
The table below shows the list of clients that support certificate revocation checking.
Clients that Support Certificate Revocation Checking
| Authentication Source | Certificate Revocation Checking Supported |
|---|---|
| SMF client | Yes |
| MQTT client | Yes |
| REST publisher | Yes |
| REST subscriber | No |
| Web Messaging client | Yes |
For information on certificate revocation configurations, see Configuring Certificate Authorities.
Certificate Revocation Checking Methods
You can configure event brokers to check the revocation status of client certificates using Certificate Revocation List (CRL), Online Certificate Status Protocol (OCSP), or OCSP-CRL (a combination of both the methods).
CRL
CRL contains a list of certificates that have been revoked by the issuing CA. The URL to the CAs certificate revocation list is embedded in each certificate. The event broker downloads the CRL from the distribution point and keeps a local copy that it refreshes periodically. To authenticate client certificates, the verifying application uses the CRL URL to download a local copy of the CRL, which it then uses for every revocation check that CA needs to make. The revocation status of all the certificates in the chain and its issuing CA is checked—starting from the last issued certificate—to the root CA itself. If the serial numbers of the certificates do not appear in the CRL, then the certificates pass the revocation check.
During CRL revocation check, the root CA gets two counts because it is checking itself once and checking the CA below in the chain once. All the other CAs get one count because they are only checking the one below them or, in the case of the last CA in the chain, it's checking the client that tried to connect.
To enable CRL certificate revocation checking, see Configuring CRL Certificate Revocation Checking.
OCSP
OCSP allows an event broker to check the revocation status of a single certificate directly with the CA or through a trusted responder (OCSP responder) inside the firewall. The client certificate contains a URL of the issuer of the certificate, which is used to check the revocation status of the certificate. With the OCSP method, each certificate in the chain is verified by sending a request with the certificate’s serial number to an OCSP responder. The responder must reply to indicate if the certificate has been revoked or whether it is valid or unknown.
To enable OCSP certificate revocation checking, see Configuring OCSP Certificate Revocation Checking.
OCSP-CRL
When both the OCSP and CRL certificate revocation checking are used, the revocation status of all the certificates in the chain will be first checked by OCSP. If the result is valid, unknown or revoked, the check is complete. If the OCSP responder returns unknown (response timeout) or unavailable, then the certificate will be checked by the CRL. This process is performed on each certificate in the chain.
To enable OCSP-CRL certificate revocation checking, see Configuring OCSP-CRL Certificate Revocation Checking.