Connecting two queue managers using one-way authentication

Connecting two queue managers using one-way authentication

Follow these sample instructions to modify a system with mutual authentication to allow a queue manager to connect using one-way authentication to another; that is, when the SSL/TLS client does not send a certificate.

About this task

Scenario:

Your two queue managers (QM1 and QM2) have been set up as in Use CA-signed certificates for mutual authentication of two queue managers.
You want to change QM1 so that it connects using one-way authentication to QM2.
The resulting configuration looks like this:
Figure 1. Queue managers allowing one-way authentication

Procedure
Remove the personal certificate of QM1 from its key repository:

Removing a certificate on IBM® i systems.
Removing a certificate on UNIX, Linux , and Windows.
Removing a certificate on z/OS® systems. Perform this step twice, to remove both the personal certificate for QMA, and the default certificate.
For details of how certificates are labeled, see Digital certificate labels.
Optional: On QM1, if any SSL/TLS channels have run previously, refresh the SSL/TLS environment , as described in Refreshing the TLS environment .
Allow anonymous connections on the receiver , as described in Allowing anonymous connections on a receiver channel .
Key repositories and channels are changed as illustrated in Figure 1

If the sender channel was not running, start it. Note: If the sender channel was running and you issued the REFRESH SECURITY TYPE(SSL) command (in step 2), the channel restarts automatically. At the server end of the channel, the presence of the peer name parameter value on the channel status display indicates that a client certificate has flowed.
Verify that the task has been completed successfully by issuing some DISPLAY commands. If the task was successful, the resulting output is similar to that shown in the following examples:
From the QM1 queue manager, enter the following command:
DISPLAY CHS(TO.QM2) SSLPEER SSLCERTI
The resulting output will be similar to the following example:
DISPLAY CHSTATUS(TO.QMB) SSLPEER SSLCERTI
     4 : DISPLAY CHSTATUS(TO.QMB) SSLPEER
AMQ8417: Display Channel Status details.
   CHANNEL(TO.QM2)                         CHLTYPE(SDR)
   CONNAME(192.0.0.1)                      CURRENT
   RQMNAME(QM2)
   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=QMB,OU=IBM MQ Development,O=IBM,ST=Hampshire,C=UK")
   STATUS(RUNNING)                         SUBSTATE(MQGET)
   XMITQ(QM2)
From the QM2 queue manager, enter the following command:
DISPLAY CHS(TO.QM2) SSLPEER SSLCERTI
The resulting output will be similar to the following example:
DISPLAY CHSTATUS(TO.QM2) SSLPEER SSLCERTI
     5 : DISPLAY CHSTATUS(TO.QM2) SSLPEER SSLCERTI
AMQ8417: Display Channel Status details.
   CHANNEL(TO.QM2)                         CHLTYPE(RCVR)
   CONNAME(192.0.0.2)                      CURRENT
   RQMNAME(QMA)                            SSLCERTI( )
   SSLPEER( )                              STATUS(RUNNING)
   SUBSTATE(RECEIVE)                       XMITQ( )
On QM2, the SSLPEER field is empty, showing that QM1 did not send a certificate. On QM1, the value of SSLPEER matches that of the DN in QM2's personal certificate.
Parent topic: Connecting two queue managers using SSL/TLS