+

Search Tips | Advanced Search

Connecting two queue managers using SSL/TLS

Secure communications that use the TLS cryptographic security protocols involve setting up the communication channels and managing the digital certificates that you will use for authentication.

To set up your SSL/TLS installation you must define your channels to use TLS. You must also obtain and manage your digital certificates. On a test system, we can use self-signed certificates or certificates issued by a local certificate authority (CA). On a production system, do not use self-signed certificates.

For full information about creating and managing certificates, see the following topics:

This collection of topics introduces the tasks involved in setting up SSL/TLS communications, and provides step-by-step guidance on completing those tasks.

You might also want to test SSL/TLS client authentication, which are an optional part of the protocols. During the SSL/TLS handshake, the SSL/TLS client always obtains and validates a digital certificate from the server. With the IBM MQ implementation, the SSL/TLS server always requests a certificate from the client. Notes:
  1. In this context, an SSL/TLS client refers to the connection initiating the handshake.
  2. When a z/OS queue manager is acting in the role of an SSL/TLS client, the queue manager sends only a certificate.

The SSL/TLS client sends a certificate only if it can find a certificate with a matching label. See Digital certificate labels for details.

The SSL/TLS server always validates the client certificate if one is sent. If the client does not send a certificate, authentication fails only if the end of the channel that is acting as the SSL/TLS server is defined with either the SSLCAUTH parameter set to REQUIRED or an SSLPEER parameter has a value set. For more information about connecting a queue manager anonymously, that is, when the SSL/TLS client does not send a certificate, see Connecting two queue managers using one-way authentication.