TLS / SSL Encryption
By default, clients use plaintext over TCP to exchange data with PubSub+ software event brokers and appliances and the data that is exchanged is not compressed or encrypted.
However, event brokers can be configured to allow clients to use Transport Layer Security (TLS)/ Secure Sockets Layer (SSL) encrypted connections when using various messaging protocols, such as SMF, MQTT, AMQP, REST, or the Solace Element Management Protocol (SEMP). To enable this encryption, administrators must set a server certificate and configure specific TCP ports for TLS. PubSub+ Cloudevent broker services use TLS/SSL by default
Using TLS/SSL-encrypted connections to an event broker offers:
- Confidentiality—Messages cannot be intercepted in transit.
- Message integrity—Messages cannot be modified or tampered with in transit.
- Server authentication—The connected application is able to verify the server identity.
- 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 on the event broker message bus.
Client applications can establish secure TLS/SSL connections to properly configured event brokers using PubSub+ Messaging APIs. This requires:- A trusted server certificate on the event broker.
- The appropriate connection URL scheme and port.
- SMF:
tcps://my.broker:55443(secure) vstcp://my.broker:55555(plain) - WebSocket:
wss://my.broker:443(secure) vsws://my.broker:80(plain)
- 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 PubSub+ Messaging API to establish a client connection, SEMP requests and replies can be sent over the event broker message bus. A secure connection 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.
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, and establishing a new secure connection, require processing power, enabling TLS/SSL encryption may cause a reduction in performance and connection rates.
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 and DHE), and Elliptic Curve Diffie-Hellman (ECDH and ECDHE).
- Authentication—This algorithm is the digital signature used to authenticate the server (or client application) by proving possession of the private key matching the certificate presented during connection establishment. Common examples include: Examples: RSA (Rivest-Shamir-Adleman), DSA (Digital Signature Algorithm), and ECDSA (Elliptic Curve Digital Signature Algorithm).
- Encryption—This algorithm encrypts and decrypts payload passed on the secure connection. Examples: ChaCha20 and Advanced Encryption Standard (AES).
- Digest—This algorithm is used to maintain message integrity. Tampering with the message would render the digest invalid. Example: SHA2.
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 when using TLS 1.2 and earlier:
- 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 when using TLS 1.2 and earlier:
- 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 when you use TLS 1.2. For information about cipher suites when you use TLS 1.3, see Supported Cipher Suites when using TLS 1.3. The list is sorted from strongest to weakest.
| OpenSSL name | IANA name | Default Security Policy | FIPS Compliant Security Policy | |
|---|---|---|---|---|
|
ECDHE-ECDSA-AES256-GCM-SHA384 |
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 |
Supported |
Supported |
|
|
ECDHE-ECDSA-AES128-GCM-SHA256 |
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 |
Supported |
Supported |
|
|
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 |
Installing an ECDSA server certificate will break compatibility with older PubSub+ Messaging API and event broker versions that do not support TLS 1.3. Ensure you update all your event broker instances and client applications to support TLS 1.3 before proceeding.
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 Cipher Suites when using TLS 1.3
TLS 1.3 simplifies cipher suite configuration by using just two components:
- An AEAD (Authenticated Encryption with Associated Data) algorithm that protects data during transmission
- A digest algorithm that verifies the security of the initial TLS connection handshake
The following table lists the available TLS 1.3 cipher suites and their corresponding encryption and digest algorithms:
| Cipher Suite | AEAD Algorithm | Digest Algorithm |
|---|---|---|
|
TLS_AES_256_GCM_SHA384 |
AES GCM (256) |
SHA2 |
|
TLS_AES_128_GCM_SHA256 |
AES GCM (128) |
SHA2 |
|
TLS_CHACHA20_POLY1305_SHA256 |
CHACHA20_POLY1305 |
SHA2 |
Supported Key Exchange Mechanisms in TLS 1.3
TLS 1.3 uses Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange with the following supported groups:
- secp256r1
- secp384r1
- secp521r1
- x25519
Supported Authentication Algorithms in TLS 1.3
TLS 1.3 supports two types of authentication algorithms:
- Elliptic Curve Digital Signature Algorithm (ECDSA)—Using curves:
- secp256r1
- secp384r1
- secp521r1
- RSA Probabilistic Signature Scheme (RSASSA-PSS)—Using hash functions:
- SHA-256
- SHA-384
- SHA-512
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
For connections using TLS 1.2 and earlier, 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. When you use TLS 1.3, cipher suites are predefined by the protocol and cannot be configured in this way.
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) |
|
sha224WithECDSAEncryption sha256WithECDSAEncryption sha384WithECDSAEncryption sha512WithECDSAEncryption |
Supported |
Supported |
| Signature Algorithm | Hex Code | Default Security Policy | FIPS Compliant Security Policy |
|---|---|---|---|
|
ecdsa_secp256r1_sha256 |
0x0403 |
Supported |
Supported |
|
ecdsa_secp384r1_sha384 |
0x0503 |
Supported |
Supported |
|
ecdsa_secp521r1_sha512 |
0x0603 |
Supported |
Supported |
|
rsa_pss_pss_sha256 |
0x0809 |
Supported |
Supported |
|
rsa_pss_rsae_sha256 |
0x0804 |
Supported |
Supported |
|
rsa_pss_pss_sha384 |
0x080a |
Supported |
Supported |
|
rsa_pss_rsae_sha384 |
0x0805 |
Supported |
Supported |
|
rsa_pss_pss_sha512 |
0x080b |
Supported |
Supported |
|
rsa_pss_rsae_sha512 |
0x0806 |
Supported |
Supported |
|
rsa_pkcs1_sha256 |
0x0401 |
Supported |
Supported |
|
rsa_pkcs1_sha384 |
0x0501 |
Supported |
Supported |
|
rsa_pkcs1_sha512 |
0x0601 |
Supported |
Supported |
Installing an ECDSA server certificate will break compatibility with older versions of the PubSub+ Messaging APIs and event broker versions that do not support TLS 1.3. Ensure you update all your event broker instances and client applications to support TLS 1.3 before proceeding.
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.
- 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
PubSub+ event brokers use three lists of certificate authorities (CA):
- 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
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 certificate revocation checking, see Certificate Revocation Checking Methods
Clients That Support Certificate Revocation Checking
The following table shows the list of 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 a Certificate Revocation List (CRL), Online Certificate Status Protocol (OCSP), or OCSP-CRL (a combination of both the methods).
CRL
CRLs contain 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.