Transport Security

By default, the clients use single TCP connections to exchange plain text data over TCP with Solace routers, and the data that is exchanged is not compressed.

However, clients can use Transport Layer Security (TLS)/Secure Sockets Layer (SSL)‑encrypted connections to a Solace router so that they can exchange uncompressed Solace Message Format (SMF) data or Solace Element Management Protocol (SEMP) data with the Solace router using TLS/SSL over single TCP connections instead of plain text over TCP.

Using TLS/SSL-encrypted connections to a router 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, refer to Client Authentication/Authorization)

The follow types of applications can establish TLS/SSL-encrypted connections to a Solace router:

  • Client applications that publish and/or receive messages.
  • By default, when a client application connects to a Solace router 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 a Solace router.

    Client applications can use the Solace messaging APIs for Java, Java RTO, C, .NET, or JMS to establish secure connections to a Solace router.

  • Network management applications that manage and monitor the Solace router 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 router 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 router allows the application to send SEMP requests wrapped in HTTP to a management interface on the router 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 router, 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 Solace routers over bridges are secure.

Note:  Because encrypting and decrypting data requires processing power, enabling TLS/SSL encryption may cause a reduction in performance.

Supported Cipher Suites

The following cryptographic algorithms are used throughout the life of a TLS/SSL‑encrypted connection:

  1. Key establishment—This algorithm is used to exchange or agree on the symmetric keys to be used for encrypting and decrypting the data payload that passed on the session. Examples: RSA, Diffie-Hellman (DH), Ephemeral Diffie-Hellman (DHE), and Elliptic Curve Diffie-Hellman (ECDH).
  2. 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).
  3. Encryption—This algorithm encrypts and decrypts payload passed on the secure session. Examples: RC4, 3DES CBC, and Advanced Encryption Standard (AES).
  4. 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.

Supported Cipher Suites

Cipher Suites
(strongest to weakest)

Key Establish.

Authent.

Encryption

Digest

ECDHE-RSA-AES256-GCM-SHA384

ECDH

RSA

AES GCM (256)

SHA2

ECDHE-RSA-AES256-SHA384

ECDH

RSA

AES CBC (256)

SHA2

ECDHE-RSA-AES256-SHA

ECDH

RSA

AES CBC (256)

SHA1

AES256-GCM-SHA384

RSA

RSA

AES GCM (256)

SHA2

AES256-SHA256

RSA

RSA

AES CBC (256)

SHA2

AES256-SHA

RSA

RSA

AES CBC (256)

SHA1

ECDHE-RSA-DES-CB3-SHA

ECDH

RSA

3DES CBC (168)

SHA1

DES-CBC3-SHA

RSA

RSA

3DES CBC (168)

SHA1

ECDHE-RSA-AES128-GCM-SHA256

ECDH

RSA

AES GCM (128)

SHA2

ECDHE-RSA-AES128-SHA256

ECDH

RSA

AES CBC (128)

SHA2

ECDHE-RSA-AES128-SHA

ECDH

RSA

AES CBC (128)

SHA1

AES128-GCM-SHA256

RSA

RSA

AES GCM (128)

SHA2

AES128-SHA256

RSA

RSA

AES CBC (128)

SHA2

AES128-SHA

RSA

RSA

AES CBC (128)

SHA1

Note:   

  • 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.
  • The following GCM cipher suites are not supported by Java and are thus not supported in the JMS and Java Messaging APIs:
    • ECDHE-RSA-AES256-GCM-SHA384
    • AES256-GCM-SHA384
    • ECDHE-RSA-AES128-GCM-SHA256
    • AES128-GCM-SHA256

Supported Signature Algorithms

A Solace router can a validate a certificate chain if all certificates in the chain are signed with one of the following signature algorithms:

  • md2withRSAEncryption
  • md4withRSAEncryption
  • md5withRSAEncryption
  • shawithRSAEncryption
  • sha1withRSAEncryption
  • sha1withDSAEncryption
  • sha224withRSAEncryption
  • sha224withDSAEncryption
  • sha256withRSAEncryption
  • sha256withDSAEncryption
  • sha384withRSAEncryption
  • sha512withRSAEncryption

Server Certificates Authentication Process

The following process is used when a client or management application connects to a Solace router and requires certificate validation to establish a secure connection.

Certificate Validation Process Using TLS/SSL

  1. The client or management application connects to the router’s TLS/SSL listening port.
  2. The router responds to the client or management application with its server certificate.
  3. If an Active/Active redundancy configuration is used, each router 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 router as the common name.

  4. 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.
  5. If the validation succeeds, the client or management application will respond and continue to complete the handshake.

Client Certificates Authentication Process

The following process is used when a client application attempts to connect to a Solace router using a client certificate issued by a recognized Certificate Authority (CA).

Note:  A basic knowledge of X.509 certificates is assumed.

Client Certificate Authentication Process Using TLS/SSL

  1. The client or management application connects to the router’s TLS/SSL listening port.
  2. The router responds to the client or management application with its server certificate.
    If an Active/Active redundancy configuration is used, each router 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 router as the common name.
  3. 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.
  4. The client presents a client certificate to the Solace router.
  5. The client certificate is validated against CA certificates configured on the Solace Router.
  6. If the validation succeeds, the client or management application will respond and continue to complete the handshake.

For more information, see Client Certificate Authentication.

Certificate Authorities

A Solace appliance allows clients to authenticate over TLS by presenting a valid client certificate issued by a Certificate Authority (CA). Each participating router must be configured with a list of CAs to be trusted so that the clientʾs certificate obtained during the security protocol exchanges can be verified. The process of configuring each CA in the client certificate chain is required for authentication and is a mandatory step in trusting a CA. A Solace appliance can also be configured to use a CA with certificate revocation checking.

Note:  Configuring certificate authorities and certificate revocation checking to authenticate client certificates are only supported for appliances using SolOS version 8.2.0 or higher. For Solace VMRs and appliances using SolOS version before 8.2.0, trusted roots are still used to authenticate client certificates.

Certificate Revocation Checking

As of SolOS version 8.2.0, checking the revocation status of client certificates is supported for Solace appliances. Before this release, while validating the client certificates, the router did not check the revocation status of the certificates.

A Solace appliance can check the revocation status of the certificate that clients use when attempting to authenticate. The certificate revocation is configurable on a per-router basis with override options per-Message VPN.

The revocation status of a certificate chain can have one of the following states:

  • Good—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.
  • Revoked—One or more certificate in the chain have been revoked.

Certificate revocation checking is a router-wide feature; if the certificate revocation checking is enabled, the revocation status of all the certificates will be checked.

The table below shows the list of clients that support certificate revocation checking.

Clients That Support Certificate Revocation Checking

Authentication Source Certificate Checking Supported
SMF client Yes
MQTT client Yes
REST publisher Yes
REST subscriber No
MQTT client Yes
Web Messaging client Yes

For information on certificate revocation configurations, see Managing Certificate Authorities.

Certificate Revocation Checking Methods

You can configure Solace routers 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—A CRL contains a list of certificates that have been revoked by their issuing CA. When CRL checking is enabled the revocation status of the client certificates (and any other certificates in the chain) are checked by searching the certificates serial number in the CRL. Each certificate in the chain —starting from the last issued certificate—to the root CA itself is checked. For the chain to be deemed “Good” each certificate in the chain must pass its CRL check. The CRLs are pre-fetched and each CA must be configured with a URL pointing to a location where the CRL can be obtained if any form of CRL checking is to be used.

    Note:  The self-signed root CA is also revocation checked in its own CRL, which leads to an extra check when verifying a certificate chain. All the other CAs are checked once because they are only checking the CA they issued 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 the revocation status of a certificate to be checked directly with the issuing CA or a trusted delegate responder. When OCSP checking is enabled, client certificates (and any other certificates in the chain) are verified by sending a request with the certificate’s serial number to an OCSP responder for the CA that issued the certificate. The responder will reply with the status of the certificate—Good, Unknown, or Revoked. For the chain to be deemed "Good," the response from the OCSP responder must be “Good” for each certificate in the chain; if any responder responds with a “Revoked” response, then the whole chain is revoked. By default the URL of the OCSP responder is obtained from a field contained in the certificate; optionally an override location can be specified if the default location is unreachable.

    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. The check is complete if the OCSP responder returns with a definitive result. If the result is unknown due to response timeout or connection failure then the certificates will be checked against the CRL.

    To enable OCSP-CRL certificate revocation checking, see Configuring OCSP-CRL Certificate Revocation Checking.