Securing channels with TLS

The TLS (Transport Layer Security) protocol enables queue managers to communicate securely with other queue managers, or clients.

About this task

TLS Concepts

An TLS-enabled connection is secure in the following ways:

• Authentication: Queue managers or clients initiating an TLS-enabled connection are assured of the identity of the queue manager that they are connecting to, and queue managers that are receiving connections can check the identity of the queue manager or client that is initiating the connection.
• Message privacy: Using a unique session key, TLS, if configured to do so, encrypts all information exchanged over the connection. This ensures that information cannot be viewed if it is intercepted by unauthorized parties.
• Message integrity: The data cannot be tampered with over the connection.
• Certificate Authority chain: Each certificate in the Certificate Authority (CA) chain is signed by the entity that is identified by its parent certificate in the chain. At the head of the chain is the root CA certificate. The root certificate is always signed by the root CA itself. The signatures of all certificates in the chain must be verified.

Sequence overview

There are two stages to the security, as described in the following steps.

Procedure

1. When a queue manager connects to another queue manager, the two carry out a standard TLS exchange of certificates, and carry out validation checks. If the validation is successful, the connection is established. To achieve this, you must configure both of your queue managers, and the channels that they will use, with appropriate certificate settings.
2. When messages are sent from one queue manager to another queue manager along a channel, the data is generally encrypted using a session key that has been established during the certificate exchange. To achieve this you must configure the channels that you will use with appropriate CipherSpecs.

Results

Sequence Details

A typical sequence for a simple TLS connection between queue managers QM1 and QM2 is as follows:

1. QM1 connects to QM2.
2. The personal certificate that is used by QM2 is sent to QM1.
3. QM1 authenticates the personal certificate against the chain of certificate authority certificates.
4. QM1 optionally checks for certificate revocation if Online Certificate Status Protocol (OCSP) is supported on the server platform. For more information on OCSP see: Working with Online Certificate Status Protocol (OCSP).
5. QM1 optionally checks the personal certificate against the Certificate Revocation List (CRL). For more information see: Configure TLS on queue managers.
6. QM1 optionally applies a filter to only accept personal certificates that meet any defined peer names. For more information see: Configure TLS channels.
7. QM1 (if all is well) accepts the personal certificate from QM2.
8. The secure connection is now established.

For more security, QM2 can request a certificate from QM1, and in that case the following steps also take place:

1. QM1 sends its assigned personal certificate to QM2.
2. QM2 applies the same checks (Steps 3, 4, and 5) as previously shown.
3. QM2, if all is well, accepts the personal certificate from QM1.

The secure connection is now established.

For more information, see Securing in the IBM MQ online product documentation.