Use 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:

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

1. 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).
2. Create self-signed certificates for the client and queue manager:
   • On UNIX, Linux, and Windows systems.
   • On z/OS systems (queue manager only).
3. Extract a copy of each certificate:
   • On UNIX, Linux, and Windows systems.
   • On z/OS systems.
4. 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 .
5. Add the partner certificate to the key repository for the client and queue manager:
   • On UNIX, Linux, and Windows systems.
   • On z/OS systems.
6. Define a client-connection channel in either of the following ways:
   • Use the MQCONNX call with the MQSCO structure on C1, as described in Creating a client-connection channel on the IBM MQ MQI client.
   • Use a client channel definition table, as described in Creating server-connection and client-connection definitions on the server.
7. 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.