Use self-signed certificates for mutual authentication of two queue managers
Follow these sample instructions to implement mutual authentication between two queue managers, using self-signed TLS certificates.
Scenario:
- We have two queue managers, QM1 and QM2, which need to communicate securely. You require mutual authentication to be carried out between QM1 and QM2.
- We have decided to test your secure communication using self-signed certificates.
The resulting configuration looks like this:
In Figure 1, the key repository for QM1 contains the certificate for QM1 and the public certificate from QM2. The key repository for QM2 contains the certificate for QM2 and the public certificate from QM1.
Procedure
-
Prepare the key repository on each queue manager, according to operating system:
-
Create a self-signed certificate for each queue manager:
-
Extract a copy of each certificate:
- Transfer the public part of the QM1 certificate to the QM2 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 each queue manager:
-
On QM1, define a sender channel and associated transmission queue, by issuing commands like the
following example:
DEFINE CHANNEL(QM1.TO.QM2) CHLTYPE(SDR) TRPTYPE(TCP) CONNAME(QM1.MACH.COM) XMITQ(QM2) SSLCIPH(TLS_RSA_WITH_AES_128_CBC_SHA) DESCR('Sender channel using TLS from QM1 to QM2') DEFINE QLOCAL(QM2) USAGE(XMITQ)
This example uses CipherSpec TLS_RSA. The CipherSpecs at each end of the channel must be the same. -
On QM2, define a receiver channel, by issuing a command like the following example:
DEFINE CHANNEL(QM1.TO.QM2) CHLTYPE(RCVR) TRPTYPE(TCP) SSLCIPH(TLS_RSA_WITH_AES_128_CBC_SHA) SSLCAUTH(REQUIRED) DESCR('Receiver channel using TLS from QM1 to QM2')
The channel must have the same name as the sender channel you defined in Step 6, and use the same CipherSpec. - Start the channel, as described in Starting the sender channel .
Results
Key repositories and channels are created as illustrated in Figure 1What 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 examples.
From queue manager QM1, enter the following command:DISPLAY CHS(QM1.TO.QM2) SSLPEER SSLCERTIThe resulting output is like the following example:
DISPLAY CHSTATUS(QM1.TO.QM2) SSLPEER SSLCERTI 4 : DISPLAY CHSTATUS(QM1.TO.QM2) SSLPEER SSLCERTI AMQ8417: Display Channel Status details. CHANNEL(QM1.TO.QM2) CHLTYPE(SDR) CONNAME(9.20.25.40) CURRENT RQMNAME(QM2) SSLCERTI("CN=QM2,OU=<Department>,O=<Organization>,ST=<State>,C=<Country>") SSLPEER("SERIALNUMBER=4C:D0:49:D5:02:5E:02,CN=QM2,OU=<Department>,O=<Organization>,ST=<State>,C=<Country>") STATUS(RUNNING) SUBSTATE(MQGET) XMITQ(QM2)From queue manager QM2, enter the following command:
DISPLAY CHS(QM1.TO.QM2) SSLPEER SSLCERTIThe resulting output is like the following example:
DISPLAY CHSTATUS(QM1.TO.QM2) SSLPEER SSLCERTI 5 : DISPLAY CHSTATUS(QM1.TO.QM2) SSLPEER SSLCERTI AMQ8417: Display Channel Status details. CHANNEL(QM2.TO.QM1) CHLTYPE(RCVR) CONNAME(9.20.35.92) CURRENT RQMNAME(QM1) SSLCERTI("CN=QM1,OU=<Department>,O=<Organization>,ST=<State>,C=<Country>") SSLPEER("SERIALNUMBER=4C:D0:49:D5:02:5F:38,CN=QM1,OU=<Department>,O=<Organization>,ST=<State>,C=<Country>") STATUS(RUNNING) SUBSTATE(RECEIVE) XMITQ( )
In each case, the value of SSLPEER must match that of the DN in the partner certificate that was created in Step 2. The issuers name matches the peer name because the certificate is self-signed .
SSLPEER is optional. If it is specified, its value must be set so that the DN in the partner certificate (created in Step 2) is allowed. For more information about the use of SSLPEER, see IBM MQ rules for SSLPEER values.
Parent topic: Connect two queue managers using SSL/TLS