Use CA-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 CA-signed TLS certificates.

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.
In the future you are planning to use this network in a production environment, and therefore we have decided to use CA-signed certificates from the beginning.

The resulting configuration looks like this:

Figure 1. Configuration resulting from this task

In Figure 1, the key repository for C1 contains certificate for C1 and the CA certificate. The key repository for QM1 contains the certificate for QM1 and the CA certificate. In this example both C1's certificate and QM1's certificate were issued by the same CA. If C1's certificate and QM1's certificate were issued by different CAs then the key repositories for C1 and QM1 must contain both CA certificates.

Procedure

Prepare the key repository on the client and queue manager, according to operating system:
- On IBM® i systems.
- On UNIX, Linux , and Windows systems.
- On z/OS® systems (queue manager only).
Request a CA-signed certificate for the client and queue manager. You might use different CAs for the client and queue manager.
- On IBM i systems.
- On UNIX, Linux, and Windows systems.
- On z/OS systems (queue manager only).
Add the certificate authority certificate to the key repository for the client and queue manager. If the client and queue manager are using different Certificate Authorities then the CA certificate for each Certificate Authority must be added to both key repositories.
- Do not perform this step on IBM i systems.
- On UNIX, Linux, and Windows systems.
- On z/OS systems (queue manager only).
Receive the CA-signed certificate to the key repository for the client and queue manager:
- On IBM i systems.
- On UNIX, Linux, and Windows systems.
- On z/OS systems (queue manager only).
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.
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 like that shown in the following example.

From the queue manager QM1, enter the following command:

DISPLAY CHSTATUS(TO.QMB) 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=IBM MQ CA,OU=IBM MQ Devt,O=IBM,ST=Hampshire,C=UK")
   SSLPEER("SERIALNUMBER=4C:D0:49:D5:02:5F:38,CN=QMA,OU=IBM MQ Development,O=IBM,ST=Hampshire,C=UK")
   STATUS(RUNNING)                         SUBSTATE(RECEIVE)

The SSLPEER field in the DISPLAY CHSTATUS output shows the subject DN of the remote client certificate that was created in Step 2. The issuer name matches the subject DN of the CA certificate that signed the personal certificate added in Step 4.