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 or TLS client does not send a certificate.

About this task

Scenario:

• Your two queue managers (QM1 and QM2) have been set up as in Using 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:

1. 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 systems.
   • 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 cetificates are labeled, see Digital certificate labels.
2. Optional: On QM1, if any SSL or TLS channels have run previously, refresh the SSL or TLS environment , as described in Refreshing the SSL or TLS environment .
3. 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

4. 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.
5. 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(9.20.25.40)                     CURRENT
        RQMNAME(QM2)
        SSLCERTI("CN=WebSphere MQ CA,OU=WebSphere MQ Devt,O=IBM,ST=Hampshire,C=UK")
        SSLPEER("SERIALNUMBER=4C:D0:49:D5:02:5F:38,CN=QMB,OU=WebSphere 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(9.20.35.92)                     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.