Using self-signed certificates for mutual authentication of a client and queue manager

Follow these sample instructions to implement mutual authentication between a client and a queue manager, by using self-signed TLS certificates.

About this task

Scenario:

You have a client, C1, and a queue manager, QM1, which need to communicate securely. You require mutual authentication to be carried out between C1 and QM1.
You have decided to test your secure communication by using self-signed certificates.

DCM on IBM® i does not support self-signed certificates, so this task is not applicable on IBM i systems.

The resulting configuration looks like this:

The client C1 is linked to queue manager QM1 by the channel CHANNEL1. The client and queue manager each have a key repository, described in the following text. — Figure 1. Configuration resulting from this task

In Figure 1, the key repository for QM1 contains the certificate for QM1 and the public certificate from C1. The key repository for C1 contains the certificate for C1 and the public certificate from QM1.

Procedure

Prepare the key repository on the client and queue manager, according to operating system:
- On UNIX, Linux®, and Windows systems.
- On z/OS® systems (queue manager only).
Create self-signed certificates for the client and queue manager:
- On UNIX, Linux, and Windows systems.
- On z/OS systems (queue manager only).
Extract a copy of each certificate:
- On UNIX, Linux, and Windows systems.
- On z/OS systems.
Transfer the public part of the C1 certificate to the QM1 system and vice versa, using a utility such as FTP , as described in Exchanging self-signed certificates .
Add the partner certificate to the key repository for the client and queue manager:
- On UNIX, Linux, and Windows systems.
- On z/OS systems.
Issue the command REFRESH SECURITY TYPE(SSL) on the queue manager.
Define a client-connection channel in either of the following ways:
- Using the MQCONNX call with the MQSCO structure on C1, as described in Creating a client-connection channel on the IBM MQ MQI client.
- Using a client channel definition table, as described in Creating server-connection and client-connection definitions on the server.
On QM1, define a server-connection channel, by issuing a command like the following example:
```
DEFINE CHANNEL(C1.TO.QM1) CHLTYPE(SVRCONN) TRPTYPE(TCP) SSLCIPH(TLS_RSA_WITH_AES_128_CBC_SHA)
SSLCAUTH(REQUIRED) DESCR('Receiver channel using TLS from C1 to QM1')
```
The channel must have the same name as the client-connection channel you defined in step 6, and use the same CipherSpec.

Results

Key repositories and channels are created as illustrated in Figure 1.

What to do next

Check that the task has been completed successfully by using DISPLAY commands. If the task was successful, the resulting output is similar to that shown in the following example.

From queue manager QM1, enter the following command:


DISPLAY CHSTATUS(C1.TO.QM1) SSLPEER SSLCERTI

The resulting output is like the following example:


DISPLAY CHSTATUS(C1.TO.QM1) SSLPEER SSLCERTI
     5 : DISPLAY CHSTATUS(C1.TO.QM1) SSLPEER SSLCERTI
AMQ8417: Display Channel Status details.
   CHANNEL(C1.TO.QM1)                    CHLTYPE(SVRCONN)
   CONNAME(192.0.0.1)                    CURRENT
   SSLCERTI("CN=QM1,OU=IBM MQ Development,O=IBM,ST=Hampshire,C=UK")
   SSLPEER("SERIALNUMBER=4C:D0:49:D5:02:5E:02,CN=QM2,OU=IBM MQ Development,O=IBM,ST=Hampshire,C=UK")
   STATUS(RUNNING)                         SUBSTATE(RECEIVE)

It is optional to set the SSLPEER filter attribute of the channel definitions. If the channel definition SSLPEER is set, its value must match the subject DN in the partner certificate that was created in Step 2. After a successful connection, the SSLPEER field in the DISPLAY CHSTATUS output shows the subject DN of the remote client certificate.