Introduction

IBM® WebSphere® MQ (hereafter referred to as WebSphere MQ) queue manager clusters provide workload balancing and reduce the cost of system administration in WebSphere MQ networks by auto-defining channels between queue managers. It is possible to secure WebSphere MQ channels using Secure Sockets Layer (SSL), which provides encryption of data, authentication of partner, and detection of message tampering.

This article describes how to enable SSL in an existing WebSphere MQ queue manager cluster. You will create a new set of channels with SSL enabled, in addition to the pre-existing non-SSL channels. Once the SSL channels are working, you will remove the non-SSL channels. Although this method is more complex than simply altering pre-existing channels, it minimises the risk of application problems, caused by channel outages, during SSL enablement.

After you enable SSL, you will learn how you can use channel net priority (NETPRTY) to alter workload balancing behaviour during SSL enablement.

The article refers to several scripts in the Download section.

Overview: Enabling SSL in the cluster

The main tasks required to enable SSL in the cluster are:

1. Administer certificates.
1. Create the queue manager key repositories
2. Create and distribute the CA certificate
3. Create the queue manager certificates
2. Set SSLKEYR on all queue managers
3. Define the new SSL channels
1. Define new cluster receivers with SSL on all the full repositories.
2. Define new cluster senders with SSL on all the full repositories.
3. Define new cluster receivers with SSL on all the partial repositories.
4. Define new cluster senders with SSL on all the partial repositories.
4. Verify that the SSL channels are working
5. Delete the non-SSL channels

Setting up a queue manager cluster

We based the example cluster on the Windows machine setup in Table 1.

Important: We defined cluster queues of the same name (QX) on all four queue managers, as this ensures that all queue managers auto-define cluster channels to one another. The tasks below require that all queue managers in the original cluster have healthy cluster channels to and from all other queue managers.

We actually ran the examples on one machine with myhost1-5 all resolving to localhost.

We used WebSphere MQ V6.0 and the certificate administration tool GSkit, which is incompatible with WebSphere MQ V5.3.

To see the commands used to create the cluster, refer to script create_qmgrs.bat in the Download section.

To see the output from DIS CHS and DIS CLUSQMGR for the pre-SSL cluster, refer to Appendix A

1. Administer certificates

Before altering WebSphere MQ objects you need to set-up key repositories and certificates for all queue managers in the cluster. You can use an external Certification Authority (CA) outside the department or company, but this example uses an internal CA and so includes the steps required to sign certificate requests. You can also use self-signed certificates, but we don’t recommend this method because of the associated high administration cost.

a. Create the queue manager key repositories

To create a key repository for each queue manager:

1. Create QM1 key repository on myhost1:

   runmqckm -keydb -create -db "C:\Program Files\IBM\WebSphere MQ\Qmgrs\QM1\ssl\qm1.kdb" -pw password -type cms -expire 365 -stash

   Important: Using a password of “password” is not recommended. Passwords should be set according to your company’s password standards.

2. Create QM2 key repository on myhost2:

   runmqckm -keydb -create -db "C:\Program Files\IBM\WebSphere MQ\Qmgrs\QM2\ssl\qm2.kdb" -pw password -type cms -expire 365 -stash

3. Create QM3 key repository on myhost3:

   runmqckm -keydb -create -db "C:\Program Files\IBM\WebSphere MQ\Qmgrs\QM3\ssl\qm3.kdb" -pw password -type cms -expire 365 -stash

4. Create QM4 key repository on myhost4:

   runmqckm -keydb -create -db "C:\Program Files\IBM\WebSphere MQ\Qmgrs\QM4\ssl\qm4.kdb" -pw password -type cms -expire 365 -stash

5. Create CA key repository on myhost5:

   runmqckm -keydb -create -db "C:\mq\ssl\wmqca.kdb" -pw password -type cms -expire 365 -stash

b. Create and distribute the CA certificate

To create a CA certificate on the Security Administrator machine and distribute the public CA certificate to each WebSphere MQ machine:

1. Create the CA certificate on myhost5:

   runmqckm -cert -create -db "C:\mq\ssl\wmqca.kdb" -pw password -labelwmqca -dn " CN=WMQ CA, OU=WMQ, O=IBM, L=Hursley, ST=Hampshire, C=UK," -expire 365

2. Check that the CA certificate is listed in the CA key repository on myhost5:

   runmqckm -cert -list -db "C:\mq\ssl\wmqca.kdb" -pw password

3. Extract the public CA certificate on myhost5:

   runmqckm -cert -extract -db"C:\mq\ssl\wmqca.kdb"-pw password -label wmqca -target wmqca.crt -format ascii

4. FTP the public CA certificate from myhost5 to myhost1.

   FTP wmqca.crt in ASCII mode from myhost5 to myhost1. Name the file on myhost1 wmqca.crt

5. Add the public CA certificate to QM1’s key repository on myhost1:

   runmqckm -cert -add -db "C:\Program Files\IBM\WebSphere MQ\Qmgrs\QM1\ssl\qm1.kdb" -pw password -label wmqca -file wmqca.crt -format ascii

6. Check that the public CA certificate is listed in QM1’s key repository on myhost1:

   runmqckm -cert -list -db "C:\Program Files\IBM\WebSphere MQ\Qmgrs\QM1\ssl\qm1.kdb" -pw password

7. To distribute the public CA certificate to the other queue managers repeat steps 4 to 6 for QM2, QM3 and QM4 replacing the parameters in bold.

c. Create the queue manager certificates

To create the queue manager certificates:

1. Create QM1’s certificate request on myhost1:

   runmqckm -certreq -create -db "C:\Program Files\IBM\WebSphere MQ\Qmgrs\QM1\ssl\qm1.kdb" -pw password -label ibmwebspheremqqm1 -dn " CN=QM1, OU=WMQ, O=IBM, L=Hursley, ST=Hampshire, C=UK" -file qm1req.arm

2. FTP QM1’s certificate request from myhost1 to myhost5.

   FTP qm1req.arm in ASCII mode from myhost1 to myhost5. Name the file on myhost5 qm1req.arm.

3. Sign QM1’s certificate on myhost5:

   runmqckm -cert -sign -file qm1req.arm -db"C:\mq\ssl\wmqca.kdb" -pw password -label wmqca -target qm1cert.arm -format ascii -expire 364

4. FTP QM1’s certificate from myhost5 to myhost1.

   FTP qm1cert.arm in ASCII mode from myhost5 to myhost1. Name the file on myhost1qm1cert.arm.

5. Add QM1’s certificate to QM1’s key repository on myhost1:

   runmqckm -cert -receive -db "C:\Program Files\IBM\WebSphere MQ\Qmgrs\QM1\ssl\qm1.kdb" -pw password -file qm1cert.arm -format ascii

6. Check that QM1’s certificate is listed in QM1’s key repository on myhost1:

   runmqckm -cert -list -db "C:\Program Files\IBM\WebSphere MQ\Qmgrs\QM1\ssl\qm1.kdb" -pw password

7. To create the other queue manager certificates repeat steps 1 to 6 for QM2, QM3 and QM4 replacing the parameters in bold.

Important: GSkit commands are case sensitive. Label names for queue manager certificates should be formatted as defined in the “Working with WebSphere MQ SSL support” section of the WebSphere MQ Security manual (SC34-6588-01, see Resources).

2. Set SSLKEYR on all queue managers

To set each queue manager’s key repository:

1. Set QM1’s queue manager key repository on myhost1:

   ALTER QMGR SSLKEYR('C:\Program Files\IBM\WebSphere MQ\Qmgrs\QM1\ssl\qm1')

2. Set QM2’s queue manager key repository on myhost2:

   ALTER QMGR SSLKEYR('C:\Program Files\IBM\WebSphere MQ\Qmgrs\QM2\ssl\qm2')

3. Set QM3’s queue manager key repository on myhost3:

   ALTER QMGR SSLKEYR('C:\Program Files\IBM\WebSphere MQ\Qmgrs\QM3\ssl\qm3')

4. Set QM4’s queue manager key repository on myhost4:

   ALTER QMGR SSLKEYR('C:\Program Files\IBM\WebSphere MQ\Qmgrs\QM4\ssl\qm4')

Important: Changes to SSLKEYR may not become effective immediately. For further information see the “ALTER QMGR” section of the WebSphere MQ Script (MQSC) Command Reference manual (SC34-6597-00).

To see the commands used to define each queue manager’s key repository, refer to script alter_qmgrs_sslkeyr.bat.

3. Define the new SSL channels

Next, define the new SSL channels.

Important: Define the channels in the correct order:

1. Define new cluster receivers with SSL on all the full repositories.
2. Define new cluster senders with SSL on all the full repositories.
3. Define new cluster receivers with SSL on all the partial repositories.
4. Define new cluster senders with SSL on all the partial repositories.

The channels should be defined in this order to avoid channel errors and configuration problems. If a different order is used (e.g. the different order used in script create_ssl_channels.bat, see the Download section) the new channels should still work, but are likely to go into retry and therefore take more time to successfully start.

Before defining new SSL channels

Before defining the new SSL channels, ensure that the existing channels work correctly, as the instructions assume that changes to cluster objects are published around the cluster via running channels. Each step contains instructions that describe how to check that cluster objects have been published correctly.

At this stage every queue manager should have a key repository populated with the certificates it needs to run SSL channels. This is a good time to ensure that SSL channels work correctly before you change the existing cluster channels. To test that the SSL certificate setup has been successful:

1. Define a simple point-to-point non-cluster channel with SSL between two queue managers.
2. Start the channel.
3. Check that SSL is enabled on the channel, using DIS CHL(. . .) SSLCIPH. A non-blank SSLCIPH indicates that SSL is enabled on the channel.
4. Send some messages over the channel.
5. Check that SSL is running correctly, using DIS CHS(. . .) SSLPEER. Both ends of the channel should show their partners Distinguished Name (DN) since both queue managers have a certificate.

a. Define the new cluster receivers with SSL on all full repositories

Next, define a cluster receiver channel with SSL on all full repositories. When you define the cluster receiver channels, the other queue managers in the cluster will auto-define cluster sender channels based on the definition of the new cluster receiver channels.

1. Define a cluster receiver with SSL on full repository QM1 on myhost1:

   DEFINE CHANNEL(TO.QM1.S) CHLTYPE(CLUSRCVR) CLUSTER(DEMO) TRPTYPE(TCP) CONNAME('myhost1(1414)') SSLCIPH(TRIPLE_DES_SHA_US)

   This command creates a new cluster queue manager object on QM1. The queue manager will publish the new cluster queue manager object out to other queue managers in the cluster over the existing non-SSL channels. The other queue managers will use the new definition to create auto-defined cluster channels to QM1. The next steps check that all objects have been created correctly.

2. Check that you created the new cluster queue manager object locally on myhost1. There should now be two cluster queue manager objects for QM1 on QM1 (see Listing 1).

   If the new SSL cluster queue manager does not display, check the result of the DEFINE CHANNEL in the previous step.

   
   
   Listing 1. Output from DIS CLUSQMGR(QM1) STATUS SSLCIPH
   

   C:\>echo dis clusqmgr(QM1) status sslciph | runmqsc QM1 5724-H72 (C) Copyright IBM Corp. 1994, 2004. ALL RIGHTS RESERVED. Starting MQSC for queue manager QM1. 1 : dis clusqmgr(QM1) status sslciph AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(QM1) CHANNEL(TO.QM1.S) CLUSTER(DEMO) SSLCIPH(TRIPLE_DES_SHA_US) STATUS(RUNNING) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(QM1) CHANNEL(TO.QM1) CLUSTER(DEMO) SSLCIPH( ) STATUS(RUNNING) One MQSC command read. No commands have a syntax error. All valid MQSC commands were processed.

   
   
3. Check that the queue manager published the new cluster queue manager object correctly and that the other queue managers defined the auto-defined cluster sender channels correctly. You should now have two cluster queue manager objects for QM1 on:
   • QM2 on myhost2
   • QM3 on myhost3
   • QM4 on myhost4

   If the new SSL cluster queue manager object does not display, then QM1 didn’t publish the cluster object correctly. Check the channel from QM1 to the problem queue manager to make sure it is working properly.

   The new cluster queue manager object should have a channel status of either INACTIVE or RUNNING (see Listing 2). If the status is RETRYING, check for error messages. It is likely the DEFINE CHANNEL command on QM1 was incorrect. To fix this, simply alter the cluster receiver on QM1. There is no need to use REFRESH CLUSTER to fix a bad definition in this situation. Once the channel definition is fixed, start the RETRYING channel manually.

   
   
   Listing 2. Output from DIS CLUSQMGR(QM1) STATUS SSLCIPH
   

   C:\>echo dis clusqmgr(QM1) status sslciph | runmqsc QM2 5724-H72 (C) Copyright IBM Corp. 1994, 2004. ALL RIGHTS RESERVED. Starting MQSC for queue manager QM2. 1 : dis clusqmgr(QM1) status sslciph AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(QM1) CHANNEL(TO.QM1.S) CLUSTER(DEMO) SSLCIPH(TRIPLE_DES_SHA_US) STATUS(INACTIVE) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(QM1) CHANNEL(TO.QM1) CLUSTER(DEMO) SSLCIPH( ) STATUS(RUNNING) One MQSC command read. No commands have a syntax error. All valid MQSC commands were processed. C:\>echo dis clusqmgr(QM1) status sslciph | runmqsc QM3 5724-H72 (C) Copyright IBM Corp. 1994, 2004. ALL RIGHTS RESERVED. Starting MQSC for queue manager QM3. 1 : dis clusqmgr(QM1) status sslciph AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(QM1) CHANNEL(TO.QM1.S) CLUSTER(DEMO) SSLCIPH(TRIPLE_DES_SHA_US) STATUS(RUNNING) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(QM1) CHANNEL(TO.QM1) CLUSTER(DEMO) SSLCIPH( ) STATUS(INACTIVE) One MQSC command read. No commands have a syntax error. All valid MQSC commands were processed. C:\>echo dis clusqmgr(QM1) status sslciph | runmqsc QM4 5724-H72 (C) Copyright IBM Corp. 1994, 2004. ALL RIGHTS RESERVED. Starting MQSC for queue manager QM4. 1 : dis clusqmgr(QM1) status sslciph AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(QM1) CHANNEL(TO.QM1.S) CLUSTER(DEMO) SSLCIPH(TRIPLE_DES_SHA_US) STATUS(RUNNING) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(QM1) CHANNEL(TO.QM1) CLUSTER(DEMO) SSLCIPH( ) STATUS(INACTIVE) One MQSC command read. No commands have a syntax error. All valid MQSC commands were processed.

   
   
4. To define new cluster receivers with SSL on the other full repository repeat steps 1 to 3 for QM2 replacing the parameters in bold.

To see the commands used to create the SSL channels, refer to script create_ssl_channels.bat in the Download section.

b. Define the new cluster senders with SSL on all full repositories

Next, define the cluster sender channels with SSL on all full repositories. Because the new channel definitions are cluster senders, the queue manager will not publish the definition to other queue managers in the cluster.

1. Define a cluster sender with SSL on full repository QM1 on myhost1:

   DEFINE CHANNEL(TO.QM2.S) CHLTYPE(CLUSSDR)CLUSTER(DEMO)TRPTYPE(TCP) CONNAME('myhost2(1415)') SSLCIPH(TRIPLE_DES_SHA_US)

   Important: A cluster queue manager object with SSL for QM2 already exists on QM1, so this command will not create a new cluster queue manager object. The object already existing is an auto-defined cluster sender based on the cluster receiver definition on QM2. Defining the new manual cluster sender channel on QM1 will alter the DEFTYPE of the existing cluster queue manager object from CLUSSDRA to CLUSSDRB.

2. Check that the existing cluster queue manager object is now a CLUSSDRB (see Listing 3). You should have two cluster queue manager objects for QM2 on QM1.

   If the SSL cluster queue manager is not a CLUSSDRB, check the result of the DEFINE CHANNEL in the previous step.

   
   
   Listing 3. Output from DIS CLUSQMGR(QM2) STATUS SSLCIPH DEFTYPE
   

   C:\>echo dis clusqmgr(QM2) status sslciph deftype | runmqsc QM1 5724-H72 (C) Copyright IBM Corp. 1994, 2004. ALL RIGHTS RESERVED. Starting MQSC for queue manager QM1. 1 : dis clusqmgr(QM2) status sslciph deftype AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(QM2) CHANNEL(TO.QM2.S) CLUSTER(DEMO) DEFTYPE(CLUSSDRB) SSLCIPH(TRIPLE_DES_SHA_US) STATUS(RUNNING) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(QM2) CHANNEL(TO.QM2) CLUSTER(DEMO) DEFTYPE(CLUSSDRB) SSLCIPH( ) STATUS(RUNNING) One MQSC command read. No commands have a syntax error. All valid MQSC commands were processed.

   
   
3. To define new cluster sender with SSL on the other full repository repeat steps 1 and 2 for QM2 replacing the parameters in bold.

To see the commands used to create the SSL channels, refer to script create_ssl_channels.bat in the Download section.

c. Define the new cluster receivers with SSL on all partial repositories

Next, define the cluster receiver channels with SSL on all partial repositories. When you define the channels, other queue managers in the cluster should auto-define cluster senders. The auto-defined cluster sender channels base themselves on the definition of the new cluster receivers. The queue managers that will auto-define cluster sender channels are all the full repositories and partial repositories that subscribe to the queue manager on which the new cluster receiver channel is defined. In the cluster used in the examples every queue manager subscribes to every other queue manager.

1. Define a cluster receiver with SSL on partial repository QM3 on myhost3:

   DEFINE CHANNEL(TO.QM3.S) CHLTYPE(CLUSRCVR) CLUSTER(DEMO) TRPTYPE(TCP) CONNAME('myhost3(1416)') SSLCIPH(TRIPLE_DES_SHA_US)

   This command should create a new cluster queue manager object on QM3. The queue manager should publish the new cluster queue manager object out to other queue managers in the cluster over the other cluster channels. The other queue managers will use the new definition to create auto-defined cluster channels to QM3. The next steps check that all objects have been created correctly.

2. Check that you created the new cluster queue manager object locally on myhost3. You should now have two cluster queue manager objects for QM3 on QM3 (see Listing 4).

   If the new SSL cluster queue manager does not display, check the result of the DEFINE CHANNEL in the previous step.

   
   
   Listing 4. Output from DIS CLUSQMGR(QM3) STATUS SSLCIPH
   

   C:\>echo dis clusqmgr(QM3) status sslciph | runmqsc QM3 5724-H72 (C) Copyright IBM Corp. 1994, 2004. ALL RIGHTS RESERVED. Starting MQSC for queue manager QM3. 1 : dis clusqmgr(QM3) status sslciph AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(QM3) CHANNEL(TO.QM3.S) CLUSTER(DEMO) SSLCIPH(TRIPLE_DES_SHA_US) STATUS(INACTIVE) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(QM3) CHANNEL(TO.QM3) CLUSTER(DEMO) SSLCIPH( ) STATUS(RUNNING) One MQSC command read. No commands have a syntax error. All valid MQSC commands were processed.

   
   
3. Check that the queue manager published the new cluster queue manager object correctly and that the other queue managers defined the auto-defined cluster sender channels correctly. You should now have two cluster queue manager objects for QM3 on:
   • QM1 on myhost1
   • QM2 on myhost2
   • QM4 on myhost4

   If the new SSL cluster queue manager object does not display, the cluster object from QM3 was not published correctly. Check the channel from QM3 to the problem queue manager to make sure it is working properly.

   The new cluster queue manager object should have a channel status of either INACTIVE or RUNNING (see Listing 5). If the status is RETRYING, check for error messages. It is likely the DEFINE CHANNEL command on QM3 was incorrect. To fix this, simply alter the cluster receiver on QM3. You do not need to use REFRESH CLUSTER to fix a bad definition in this situation. Once you fix the channel definition, start the RETRYING channel manually.

   
   
   Listing 5. Output from DIS CLUSQMGR(QM3) STATUS SSLCIPH
   

   C:\>echo dis clusqmgr(QM3) status sslciph | runmqsc QM1 5724-H72 (C) Copyright IBM Corp. 1994, 2004. ALL RIGHTS RESERVED. Starting MQSC for queue manager QM1. 1 : dis clusqmgr(QM3) status sslciph AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(QM3) CHANNEL(TO.QM3.S) CLUSTER(DEMO) SSLCIPH(TRIPLE_DES_SHA_US) STATUS(INACTIVE) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(QM3) CHANNEL(TO.QM3) CLUSTER(DEMO) SSLCIPH( ) STATUS(RUNNING) One MQSC command read. No commands have a syntax error. All valid MQSC commands were processed. C:\>echo dis clusqmgr(QM3) status sslciph | runmqsc QM2 5724-H72 (C) Copyright IBM Corp. 1994, 2004. ALL RIGHTS RESERVED. Starting MQSC for queue manager QM2. 1 : dis clusqmgr(QM3) status sslciph AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(QM3) CHANNEL(TO.QM3.S) CLUSTER(DEMO) SSLCIPH(TRIPLE_DES_SHA_US) STATUS(INACTIVE) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(QM3) CHANNEL(TO.QM3) CLUSTER(DEMO) SSLCIPH( ) STATUS(RUNNING) One MQSC command read. No commands have a syntax error. All valid MQSC commands were processed. C:\>echo dis clusqmgr(QM3) status sslciph | runmqsc QM4 5724-H72 (C) Copyright IBM Corp. 1994, 2004. ALL RIGHTS RESERVED. Starting MQSC for queue manager QM4. 1 : dis clusqmgr(QM3) status sslciph AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(QM3) CHANNEL(TO.QM3.S) CLUSTER(DEMO) SSLCIPH(TRIPLE_DES_SHA_US) STATUS(INACTIVE) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(QM3) CHANNEL(TO.QM3) CLUSTER(DEMO) SSLCIPH( ) STATUS(INACTIVE) One MQSC command read. No commands have a syntax error. All valid MQSC commands were processed.

   
   
4. To define new cluster receivers with SSL on the other partial repository repeat steps 1 to 3 for QM4 replacing the parameters in bold.

To see the commands used to create the SSL channels, refer to script create_ssl_channels.bat in the Download section.

d. Define the new cluster senders with SSL on all partial repositories

Next, define the cluster sender channels with SSL on all partial repositories. Manually defined cluster sender channels should be directed at full repositories. Because the new channel definition is a cluster sender, the queue manager will not publish the definition to other queue managers in the cluster.

1. Define a cluster sender with SSL on partial repository QM3 on myhost3.

   DEFINE CHANNEL(TO.QM1.S) CHLTYPE(CLUSSDR)CLUSTER(DEMO)TRPTYPE(TCP) CONNAME('myhost1(1414)') SSLCIPH(TRIPLE_DES_SHA_US)

   Important: A cluster queue manager object with SSL for QM1 already exists on QM3, so this command will not create a new cluster queue manager object. The object already existing is an auto-defined cluster sender based on the cluster receiver definition on QM1. Defining the new manual cluster sender channel on QM3 will alter the DEFTYPE of the existing cluster queue manager object from CLUSSDRA to CLUSSDRB.

2. Check that the existing cluster queue manager object is now a CLUSSDRB. You should have two cluster queue manager objects for QM1 on QM3 (see Listing 6).

   If the SSL cluster queue manager is not a CLUSSDRB, check the result of the DEFINE CHANNEL in the previous step.

   
   
   Listing 6. Output from DIS CLUSQMGR(QM1) STATUS SSLCIPH DEFTYPE
   

   C:\>echo dis clusqmgr(QM1) status sslciph deftype | runmqsc QM3 5724-H72 (C) Copyright IBM Corp. 1994, 2004. ALL RIGHTS RESERVED. Starting MQSC for queue manager QM3. 1 : dis clusqmgr(QM1) status sslciph deftype AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(QM1) CHANNEL(TO.QM1.S) CLUSTER(DEMO) DEFTYPE(CLUSSDRB) SSLCIPH(TRIPLE_DES_SHA_US) STATUS(RUNNING) AMQ8441: Display Cluster Queue Manager details. CLUSQMGR(QM1) CHANNEL(TO.QM1) CLUSTER(DEMO) DEFTYPE(CLUSSDRB) SSLCIPH( ) STATUS(RUNNING) One MQSC command read. No commands have a syntax error. All valid MQSC commands were processed.

   
   
3. To define new cluster sender with SSL on the other partial repository repeat steps 1 and 2 for QM4 replacing the parameters in bold.

To see the commands used to create the SSL channels, refer to script create_ssl_channels.bat in the Download section.

4. Verify the SSL channels are working

Next, test whether the new channels work correctly by starting all channels and checking the channel status.

1. Start the channels on QM1
   START CHL(TO.QM2.S)
START CHL(TO.QM3.S)
START CHL(TO.QM4.S)
2. Check that the channels from QM1 are in RUNNING state and SSLPEER is non-blank (see Listing 7). A non-blank SSLPEER shows that the channel is using SSL. If the channels are not in RUNNING state check for error messages.
   

   DIS CHS(TO.QM2.S) SSLPEER
DIS CHS(TO.QM3.S) SSLPEER
DIS CHS(TO.QM4.S) SSLPEER

   
   
   Listing 7. Starting and checking the channels
   

   C:\>echo dis chs(TO.QM2.S) SSLPEER | runmqsc QM1 5724-H72 (C) Copyright IBM Corp. 1994, 2004. ALL RIGHTS RESERVED. Starting MQSC for queue manager QM1. 1 : dis chs(TO.QM2.S) AMQ8417: Display Channel Status details. CHANNEL(TO.QM2.S) CHLTYPE(CLUSSDR) CONNAME(myhost2(1415)) CURRENT RQMNAME(QM2) STATUS(RUNNING) SUBSTATE(MQGET) SSLPEER(<Partner DN>) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE) One MQSC command read. No commands have a syntax error. All valid MQSC commands were processed. C:\>echo dis chs(TO.QM3.S) SSLPEER | runmqsc QM1 5724-H72 (C) Copyright IBM Corp. 1994, 2004. ALL RIGHTS RESERVED. Starting MQSC for queue manager QM1. 1 : dis chs(TO.QM3.S) AMQ8417: Display Channel Status details. CHANNEL(TO.QM3.S) CHLTYPE(CLUSSDR) CONNAME(myhost3(1416)) CURRENT RQMNAME(QM3) STATUS(RUNNING) SUBSTATE(MQGET) SSLPEER(<Partner DN>) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE) One MQSC command read. No commands have a syntax error. All valid MQSC commands were processed. C:\>echo dis chs(TO.QM4.S) SSLPEER | runmqsc QM1 5724-H72 (C) Copyright IBM Corp. 1994, 2004. ALL RIGHTS RESERVED. Starting MQSC for queue manager QM1. 1 : dis chs(TO.QM4.S) AMQ8417: Display Channel Status details. CHANNEL(TO.QM4.S) CHLTYPE(CLUSSDR) CONNAME(myhost4(1417)) CURRENT RQMNAME(QM4) STATUS(RUNNING) SUBSTATE(MQGET) SSLPEER(<Partner DN>) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE) One MQSC command read. No commands have a syntax error. All valid MQSC commands were processed.

   
   
3. To start and check the channels on the other queue managers repeat steps 1 and 2 for QM2, QM3 and QM4 replacing the parameters in bold.

Check that the new SSL channels can transmit messages successfully

1. Put messages to remote cluster queues and check that the messages arrive on the destination queues.
2. Check that the messages were tranmitted over the SSL channels rather than the non-SSL channels by checking that the MSGS channel status parameter increments with each put:

   DIS CHS(TO.*) WHERE(CHLTYPE EQ CLUSSDR) MSGS

The queue manager will workload balance messages to each channel depending on channel status and NETPRTY, as follows:

1. SSL channel NETPRTY = non-SSL channel NETPRTY

   If both channels have equal status (e.g. RUNNING and RUNNING) the queue manager will workload balance messages round-robin to both channels.

2. SSL channel NETPRTY > non-SSL channel NETPRTY

   If both channels have equal status the queue manager will workload balance all messages to the SSL channel.

3. SSL channel NETPRTY < non-SSL channel NETPRTY

   If both channels have equal status the queue manager will workload balance all messages to the non-SSL channel.

The queue manager will workload balance all messages to a channel if it has a more preferential channel status, regardless of NETPRTY.

NETPRTY is discussed further in the “Setting other configuration options” section.

5. Delete the non-SSL channels

Once you verify that the SSL channels work, delete the non-SSL channels so that all cluster traffic is secure. If message affinities exist or messages are still being put to the SYSTEM.CLUSTER.TRANSMIT.QUEUE for the non-SSL channels, the messages could build up and become orphaned on the SYSTEM.CLUSTER.TRANSMIT.QUEUE.

You can reduce the risk of orphaning messages by stopping the non-SSL channels and only deleting them when you are certain they are not being used (i.e. no build up of messages on the SYSTEM.CLUSTER.TRANSMIT.QUEUE). When you stop the non-SSL channels the cluster workload algorithm is less likely to choose them unless an affinity exists. Once you are certain that the non-SSL channels are not being used, delete them.

Stop the non-SSL cluster sender channels

1. Stop the non-SSL cluster sender channels on QM1 on myhost1.
   STOP CHANNEL(TO.QM2)
STOP CHANNEL(TO.QM3)
STOP CHANNEL(TO.QM4)
2. Stop the non-SSL cluster sender channels on QM2 on myhost2.
   STOP CHANNEL(TO.QM1)
STOP CHANNEL(TO.QM3)
STOP CHANNEL(TO.QM4)
3. Stop the non-SSL cluster sender channels on QM3 on myhost3.
   STOP CHANNEL(TO.QM1)
STOP CHANNEL(TO.QM2)
STOP CHANNEL(TO.QM4)
4. Stop the non-SSL cluster sender channels on QM4 on myhost4.
   STOP CHANNEL(TO.QM1)
STOP CHANNEL(TO.QM2)
STOP CHANNEL(TO.QM3)

To see the commands used to stop the non-SSL channels, refer to script stop_non_ssl_channels.bat in the Download section.

Check that the non-SSL cluster sender channels are not in-use

Check that there are no messages building up on the SYSTEM.CLUSTER.TRANSMIT.QUEUE for the stopped non-SSL channels. The CURDEPTH of the SYSTEM.CLUSTER.TRANSMIT.QUEUE indicates if messages have built up for any cluster sender channel, but XQMSGSA of channel status indicates if messages have built up for specific cluster sender channels. If there are messages building up, start the channels to let the messages flow and rectify the applications with the affinity before stopping the channel and checking again.

1. Check that there are no messages building up for non-SSL cluster sender channels on QM1 on myhost1.
   DIS CHS(TO.QM2) WHERE(XQMSGSA > 0)
DIS CHS(TO.QM3) WHERE(XQMSGSA > 0)
DIS CHS(TO.QM4) WHERE(XQMSGSA > 0)

   The commands should all return “Channel Status not found.”.

2. Check that there are no messages building up for non-SSL cluster sender channels on QM2 on myhost2.
   DIS CHS(TO.QM1) WHERE(XQMSGSA > 0)
DIS CHS(TO.QM3) WHERE(XQMSGSA > 0)
DIS CHS(TO.QM4) WHERE(XQMSGSA > 0)
3. Check that there are no messages building up for non-SSL cluster sender channels on QM3 on myhost3.
   DIS CHS(TO.QM1) WHERE(XQMSGSA > 0)
DIS CHS(TO.QM2) WHERE(XQMSGSA > 0)
DIS CHS(TO.QM4) WHERE(XQMSGSA > 0)
4. Check that there are no messages building up for non-SSL cluster sender channels on QM4 on myhost4.
   DIS CHS(TO.QM1) WHERE(XQMSGSA > 0)
DIS CHS(TO.QM2) WHERE(XQMSGSA > 0)
DIS CHS(TO.QM3) WHERE(XQMSGSA > 0)

To see the commands used to check the non-SSL channels, refer to script check_non_ssl_channels.bat in the Download section.

Delete the non-SSL cluster channels

Once the non-SSL channels are no longer in use they can be deleted.

1. Delete the non-SSL cluster channels on QM1 on myhost1.
   DELETE CHL(TO.QM1)
DELETE CHL(TO.QM2)
2. Delete the non-SSL cluster channels on QM2 on myhost2.
   DELETE CHL(TO.QM2)
DELETE CHL(TO.QM1)
3. Delete the non-SSL cluster channels on QM3 on myhost3.
   DELETE CHL(TO.QM3)
DELETE CHL(TO.QM1)
4. Delete the non-SSL cluster channels on QM4 on myhost4.
   DELETE CHL(TO.QM4)
DELETE CHL(TO.QM2)

To see the commands used to delete the non-SSL channels, refer to script delete_non_ssl_channels.bat in the Download section.

Check that the non-SSL cluster queue manager objects have been deleted

1. Ensure there are no non-SSL cluster queue manager objects on QM1 on myhost1:
   DIS CLUSQMGR(*) WHERE(CHANNEL EQ TO.QM1)
DIS CLUSQMGR(*) WHERE(CHANNEL EQ TO.QM2)
DIS CLUSQMGR(*) WHERE(CHANNEL EQ TO.QM3)
DIS CLUSQMGR(*) WHERE(CHANNEL EQ TO.QM4)

   The commands should all return WebSphere MQ object not found.

2. Ensure there are no non-SSL cluster queue manager objects on QM2 on myhost2:
   DIS CLUSQMGR(*) WHERE(CHANNEL EQ TO.QM1)
DIS CLUSQMGR(*) WHERE(CHANNEL EQ TO.QM2)
DIS CLUSQMGR(*) WHERE(CHANNEL EQ TO.QM3)
DIS CLUSQMGR(*) WHERE(CHANNEL EQ TO.QM4)
3. Ensure there are no non-SSL cluster queue manager objects on QM3 on myhost3:
   DIS CLUSQMGR(*) WHERE(CHANNEL EQ TO.QM1)
DIS CLUSQMGR(*) WHERE(CHANNEL EQ TO.QM2)
DIS CLUSQMGR(*) WHERE(CHANNEL EQ TO.QM3)
DIS CLUSQMGR(*) WHERE(CHANNEL EQ TO.QM4)
4. Ensure there are no non-SSL cluster queue manager objects on QM4 on myhost4:
   DIS CLUSQMGR(*) WHERE(CHANNEL EQ TO.QM1)
DIS CLUSQMGR(*) WHERE(CHANNEL EQ TO.QM2)
DIS CLUSQMGR(*) WHERE(CHANNEL EQ TO.QM3)
DIS CLUSQMGR(*) WHERE(CHANNEL EQ TO.QM4)

This is the end of tasks required to enable SSL in the cluster.

Disabling SSL

If you encounter problems while enabling SSL you may want to turn off SSL. Three methods for achieving this are:

1. Stopping the SSL channels

   This method can be used up until Task 5. Once you define SSL channels there are two sets of channels between each queue manager (one SSL and one non-SSL). Manually stopping the SSL cluster sender channels will put them into STOPPED state, which is the least preferential state when the queue manager workload balances messages using the cluster workload algorithm. Therefore if the non-SSL channel is healthy, the queue manager should workload balance messages to the non-SSL channels. The queue manager will still workload balance messages to the SSL channels if there are affinities to them (e.g. If queues were opened bind-on-open and the open handle remains in use).

2. Altering the SSL channels

   You can use this method at any time. Altering the SSLCIPH attribute of the SSL channels to blank will turn off SSL for channels. Use the following command.

   ALTER CHL(TO.<qm>) CHLTYPE(<CLUSRCVR/CLUSSDR>) SSLCIPH(‘ ‘)

   Alter the channels in the following order:

   • All full repository cluster receivers.
   • All full repository cluster senders.
   • All partial repository cluster receivers.
   • All partial repository cluster senders.

   Use DISPLAY CLUSQMGR(<qm>) SSLCIPH to check that all the change has been published to other cluster queue managers.

   After switching off SSL, to turn it back on there is no need to start from the beginning of this document; simply alter to channels to set the SSLCIPH attribute to a non-blank value.

3. Deleting the SSL channels

   You can use this method up until Task 5. For instructions on how to delete channels, see Task 5.

Setting other configuration options

Finally you can configure NETPRTY to direct the flow over messages over selected channels and set SSLCAUTH to further secure your cluster channels.

NETPRTY

Channel network priority (NETPRTY) prioritises one set of channels over another, where the channels link the same two destinations. To minimize the risk of application outages when enabling SSL, you might want to set the channel network priority of the non-SSL channels to a value higher than that of the SSL channels. This prioritising may complicate the process because the default NETPRTY is zero, so before defining the SSL channels, you will need to alter all the non-SSL cluster receiver channels to have a NETPRTY greater than zero.

Setting the NETPRTY higher on non-SSL channels does not guarantee the non-SSL channels will transmit all messages. For example, imagine both the SSL and non-SSL channels from queue manager QMA to queue manager QMB are both in INACTIVE state and an application connects to QMA and starts putting messages to a queue on QMB. Because both channels statuses are equal, NETPRTY will choose the channel with higher network priority (i.e. the non-SSL channel). This triggers the non-SSL channel to start and so the non-SSL goes from INACTIVE to INITIALIZING to STARTING to BINDING to RUNNING. Whilst the non-SSL is in the intermediate states between INACTIVE and RUNNING it is less preferential in terms of channel state than the INACTIVE SSL channel. Therefore if the application puts messages while the non-SSL channel is starting up the queue manager could workload balance messages to the SSL channel.

If the NETPRTY of the SSL and non-SSL channels is equal, the queue manager will workload balance messages round robin to both channels. If the queue manager workload balances messages to the SSL channel, the SSL channel is not working, and the messages were put with bind-on-open, the messages will remain stuck on the SYSTEM.CLUSTER.TRANSMIT.QUEUE. If the queue manager workload balances messages to the SSL channel, the SSL channel is not working, and the messages were put with bind-not-fixed, the message will be re-workload balanced to the non-SSL channel (assuming the non-SSL channel is healthy).

SSLCAUTH

SSLCAUTH defines whether or not the SSL server carries out an authentication check on the certificate for the SSL client. The SSL client is the channel that initiates the connection (i.e. for cluster channels, the cluster sender channel). The SSL server is the channel that accepts the connection (i.e. for cluster channels, the cluster receiver channel).

If SSLCAUTH is set to REQUIRED, the SSL server always carries out the authentication check. If SSLCAUTH is set to OPTIONAL and the SSL client does not have a certificate, the SSL server does not carry out the authentication check. If SSLCAUTH is set to OPTIONAL and the SSL client does have a certificate, the SSL server carries out the authentication check on the certificate for the SSL client. The SSL client always carries out an authentication check on the certificate for the SSL server. This authentication is key to SSL architecture and so there are no attributes to control SSL server certificate authentication.

In a cluster, all valid queue managers will have a certificate, so the client side always sends its certificate and the server always carries out an authentication check on it, regardless of the SSLCAUTH value.

Important: To prevent a invalid queue manager that does not hold a certificate from connecting to the cluster, all cluster channels in an SSL secured cluster should have SSLCAUTH set to REQUIRED.

Conclusion

This article serves as a starting point when designing procedures to enable SSL in an existing WebSphere MQ cluster. Before changing production systems, you should create a full set of instructions tailored to your cluster configuration and company procedures and testing those instructions in a test environment. You should adapt the instructions based on factors such as the cluster architecture and the location of the CA. Administrators that are familiar with clustering and SSL or working in non-critical environments may choose to omit some steps used to verify administration changes or even to enable SSL on the original cluster channels.

Appendix A – The pre-SSL cluster

This section contains the output from DIS CHL and DIS CLUSQMGR for the cluster before enabling SSL.

 
C:\>echo DIS CHL(TO.*) | runmqsc QM1
5724-H72 (C) Copyright IBM Corp. 1994, 2004.  ALL RIGHTS RESERVED.
Starting MQSC for queue manager QM1.
     1 : DIS CHL(TO.*)
AMQ8414: Display Channel details.
   CHANNEL(TO.QM1)                         CHLTYPE(CLUSRCVR)
AMQ8414: Display Channel details.
   CHANNEL(TO.QM2)                         CHLTYPE(CLUSSDR)
One MQSC command read.
No commands have a syntax error.
All valid MQSC commands were processed.

 
C:\>echo DIS CHL(TO.*) | runmqsc QM2
5724-H72 (C) Copyright IBM Corp. 1994, 2004.  ALL RIGHTS RESERVED.
Starting MQSC for queue manager QM2.
     1 : DIS CHL(TO.*)
AMQ8414: Display Channel details.
   CHANNEL(TO.QM1)                         CHLTYPE(CLUSSDR)
AMQ8414: Display Channel details.
   CHANNEL(TO.QM2)                         CHLTYPE(CLUSRCVR)
One MQSC command read.
No commands have a syntax error.
All valid MQSC commands were processed.

 
C:\>echo DIS CHL(TO.*) | runmqsc QM3
5724-H72 (C) Copyright IBM Corp. 1994, 2004.  ALL RIGHTS RESERVED.
Starting MQSC for queue manager QM3.
     1 : DIS CHL(TO.*)
AMQ8414: Display Channel details.
   CHANNEL(TO.QM1)                         CHLTYPE(CLUSSDR)
AMQ8414: Display Channel details.
   CHANNEL(TO.QM3)                         CHLTYPE(CLUSRCVR)
One MQSC command read.
No commands have a syntax error.
All valid MQSC commands were processed.

 
C:\>echo DIS CHL(TO.*) | runmqsc QM4
5724-H72 (C) Copyright IBM Corp. 1994, 2004.  ALL RIGHTS RESERVED.
Starting MQSC for queue manager QM4.
     1 : DIS CHL(TO.*)
AMQ8414: Display Channel details.
   CHANNEL(TO.QM2)                         CHLTYPE(CLUSSDR)
AMQ8414: Display Channel details.
   CHANNEL(TO.QM4)                         CHLTYPE(CLUSRCVR)
One MQSC command read.
No commands have a syntax error.
All valid MQSC commands were processed.

 
C:\>echo DIS CLUSQMGR(*) | runmqsc QM1
5724-H72 (C) Copyright IBM Corp. 1994, 2004.  ALL RIGHTS RESERVED.
Starting MQSC for queue manager QM1.
     1 : DIS CLUSQMGR(*)
AMQ8441: Display Cluster Queue Manager details.
   CLUSQMGR(QM1)                           CHANNEL(TO.QM1)
   CLUSTER(DEMO)
AMQ8441: Display Cluster Queue Manager details.
   CLUSQMGR(QM2)                           CHANNEL(TO.QM2)
   CLUSTER(DEMO)
AMQ8441: Display Cluster Queue Manager details.
   CLUSQMGR(QM3)                           CHANNEL(TO.QM3)
   CLUSTER(DEMO)
AMQ8441: Display Cluster Queue Manager details.
   CLUSQMGR(QM4)                           CHANNEL(TO.QM4)
   CLUSTER(DEMO)
One MQSC command read.
No commands have a syntax error.
All valid MQSC commands were processed.

 
C:\>echo DIS CLUSQMGR(*) | runmqsc QM2
5724-H72 (C) Copyright IBM Corp. 1994, 2004.  ALL RIGHTS RESERVED.
Starting MQSC for queue manager QM2.
     1 : DIS CLUSQMGR(*)
AMQ8441: Display Cluster Queue Manager details.
   CLUSQMGR(QM1)                           CHANNEL(TO.QM1)
   CLUSTER(DEMO)
AMQ8441: Display Cluster Queue Manager details.
   CLUSQMGR(QM2)                           CHANNEL(TO.QM2)
   CLUSTER(DEMO)
AMQ8441: Display Cluster Queue Manager details.
   CLUSQMGR(QM3)                           CHANNEL(TO.QM3)
   CLUSTER(DEMO)
AMQ8441: Display Cluster Queue Manager details.
   CLUSQMGR(QM4)                           CHANNEL(TO.QM4)
   CLUSTER(DEMO)
One MQSC command read.
No commands have a syntax error.
All valid MQSC commands were processed.

 
C:\>echo DIS CLUSQMGR(*) | runmqsc QM3
5724-H72 (C) Copyright IBM Corp. 1994, 2004.  ALL RIGHTS RESERVED.
Starting MQSC for queue manager QM3.
     1 : DIS CLUSQMGR(*)
AMQ8441: Display Cluster Queue Manager details.
   CLUSQMGR(QM1)                           CHANNEL(TO.QM1)
   CLUSTER(DEMO)
AMQ8441: Display Cluster Queue Manager details.
   CLUSQMGR(QM2)                           CHANNEL(TO.QM2)
   CLUSTER(DEMO)
AMQ8441: Display Cluster Queue Manager details.
   CLUSQMGR(QM3)                           CHANNEL(TO.QM3)
   CLUSTER(DEMO)
AMQ8441: Display Cluster Queue Manager details.
   CLUSQMGR(QM4)                           CHANNEL(TO.QM4)
   CLUSTER(DEMO)
One MQSC command read.
No commands have a syntax error.
All valid MQSC commands were processed.

 

C:\>echo DIS CLUSQMGR(*) | runmqsc QM4
5724-H72 (C) Copyright IBM Corp. 1994, 2004.  ALL RIGHTS RESERVED.
Starting MQSC for queue manager QM4.
     1 : DIS CLUSQMGR(*)
AMQ8441: Display Cluster Queue Manager details.
   CLUSQMGR(QM1)                           CHANNEL(TO.QM1)
   CLUSTER(DEMO)
AMQ8441: Display Cluster Queue Manager details.
   CLUSQMGR(QM2)                           CHANNEL(TO.QM2)
   CLUSTER(DEMO)
AMQ8441: Display Cluster Queue Manager details.
   CLUSQMGR(QM3)                           CHANNEL(TO.QM3)
   CLUSTER(DEMO)
AMQ8441: Display Cluster Queue Manager details.
   CLUSQMGR(QM4)                           CHANNEL(TO.QM4)
   CLUSTER(DEMO)
One MQSC command read.
No commands have a syntax error.
All valid MQSC commands were processed.

Back to top

Download

Information about download methods

Resources

• Working with WebSphere MQ SSL support
  
  
• WebSphere MQ V6 trial download
  A no-charge trial download of WebSphere MQ V6. Includes limited online support for Windows® and Linux® installations at no charge during the trial period.
  
  
• WebSphere MQ V6 information center
  A single Eclipse-based Web portal to all WebSphere MQ V6 documentation, with conceptual, task, and reference information on installing, configuring, and using your WebSphere MQ environment.
  
  
• WebSphere MQ documentation library
  WebSphere MQ product manuals.
  
  
• WebSphere MQ product page
  Product descriptions, product news, training information, support information, and more.
  
  
• WebSphere MQ SupportPacs
  Downloadable code, documentation, and performance reports for the WebSphere MQ family of products.
  
  
• WebSphere MQ public newsgroup
  A non-IBM forum where you can get answers to your WebSphere MQ technical questions and share your WebSphere MQ knowledge with other users.
  
  
• WebSphere Business Integration products page
  For both business and technical users, a handy overview of all WebSphere Business Integration products
  
  
• developerWorks WebSphere Business Integration zone
  For developers, access to WebSphere Business Integration how-to articles, downloads, tutorials, education, product info, and more.
  
  
• WebSphere forums
  Product-specific forums where you can get answers to your technical questions and share your expertise with other WebSphere users.
  
  
• Most popular WebSphere trial downloads
  No-charge trial downloads for key WebSphere products.
  
  
• Trial downloads for IBM software products
  No-charge trial downloads for selected IBM® DB2®, Lotus®, Rational®, Tivoli®, and WebSphere® products.
  
  
• Safari Bookshelf: e-library designed for developers
  Complete search and download access to thousands of technical books for a one-time subscription fee. Free trial for new subscribers.
  
  
• developerWorks technical events and Webcasts
  Free technical sessions by IBM experts that can accelerate your learning curve and help you succeed in your most difficult software projects. Sessions range from one-hour Webcasts to half-day and full-day live sessions in cities worldwide.
  
  
• developerWorks blogs
  Ongoing, free-form columns by software experts, to which you can add your comments. Check out Grady Booch's blog on software architecture.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Overview: Enabling SSL in the cluster
• Setting up a queue manager cluster
• 1. Administer certificates
• 2. Set SSLKEYR on all queue managers
• 3. Define the new SSL channels
• 4. Verify the SSL channels are working
• 5. Delete the non-SSL channels
• Disabling SSL
• Setting other configuration options
• Conclusion
• Appendix A – The pre-SSL cluster
• Download
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere MQ
• Webcast: A smarter way to successful SOA - Information as a trusted strategic asset
• Briefing: WebSphere flexible business processes for a smarter planet
• Buy: WebSphere MQ

My developerWorks community

Dig deeper into WebSphere on developerWorks

DB2 pureScale

See how true transparent scaling architecture can be achieved on distributed platforms

Special offers