Overview

Skill Level: Advanced

Working Knowlege on SSL/TLS Certificate exchange using Self / CA Signed Techniques.

This article illustrates the technical implementation of a newly introduced MQ v8.0 Security feature wherein simultaneous usage of multiple CA Signed Certificates (Channel Level) is supported by a Single MQ Queue Manager.

Ingredients

IBM® MQ v8.0 & Above

Platform: Windows & Linux

Prerequisite: Working knowledge on SSL/TLS implementation at the Qmgr Level using Self-Signed or CA Signed techniques is recommended.

Introduction: Think about a scenario where an Orignization (A) needs to communicate securely with two difference Business Partner Orginzations (B & C) as mentioned in the below diagram. These Organizations have a different requirement about the Certificate Authority (CA) who signs the certificates. In our example, Organization B will only accept certificates signed by Certificate Authority 1 (CA1), whereas Organization C will only accept certificates signed by Certificate Authority (CA2).

In order for Organization (A) to be able to communicate with both of these Business Partners, we need a certificate that is signed by CA1 (to communicate with Org. B) and a certificate that is signed by CA2 (to communicate with Org. C). However, since a queue manager can only have One Certificate, with releases prior to V8 of MQ, you were forced into having two queue managers, one using each certificate. Now, imagine if I have 10+ Business Partners using 10+ different CAs, I need to have 10+ different Qmgrs connecting to their respective Business Partners which is definitely not an practical solution!

Through this article, I have going to demonstrate the technical implementation of using multi-certificates for each MQ Channel in a given Queue Manager as shown in the below figure.

Note: This issue can be solved using an MQIPT in front of the queue manager which is beyong the scope of this article.

A1-1

Configuration Items:

1. Create 2 Internal Certificate Authorities CA1 & CA2

2. Create 3 Qmgrs ORG_A, ORG_B & ORG_C.

3. Connect ORG_A with ORG_B using distributed SDR / RCVR Channels.

4. Connect ORG_A with ORG_C using distributed SDR / RCVR Channels.

5. Generate & Sign the ORG_A & ORG_B's Certificates using CA1.

6. Generate & Sign the ORG_A & ORG_C's Certificates using CA2.

7. Modify the SSL related parameters & start the Channels (bi-directionally) for all the Qmgrs.

Step-by-step

  1. Create Certificate Authorities

    For this demonstration, we are going to create 2 Internal Certificate Authorities i.e. CA1 & CA2 as mentioned in the below screenshots. The marked portions shows the various parameter values we have used while creating the Public Root Certificates for CA1 & CA2.

    1. Open the ikeyman utility (strmqikm) & create the keystores for CA1 & CA2. (** Stash the Password for the respective keystores **)

    2. Generate the Self-Signed Public Certificate of CA1 as shown below.

    2a

    3. Extract the Self-Signed Certificate which will act as the Public Root CA for Certificate Authority 1 as shown below.

    3-3

    4. Observe the list of keystore related files under CA1 folder.

    4-3

    4. Similarly repeat the same Steps for the Certificate Authority 2 & Extract the Self-Signed Public Cert (as shown in Step 3 for CA1) which will act as the Root CA for CA2.

    2-4

    5. Observe the list of keystore related files under CA2 folder.

    5-3

    UNIX Commands

    ################

    Create Keystore for CA1
    ######################
    1. runmqckm -keydb -create -db CA1 -pw Passw0rd -type cms -expire 365 -stash

    Create Self Signed CA1’s Root Certificate
    ######################################
    2. runmqckm -cert -create -db CA1.kdb -pw Passw0rd -label ssl_ca1 -dn “CN=Certificate Authority (CA1),O=IBM China,C=CN” -expire 365

    Extract Root Certificate
    ######################
    3. runmqckm -cert -extract -db CA1.kdb -pw Passw0rd -label ssl_ca1 -target ssl_ca1.cer -format ascii

    #############################################################################################

    Create Keystore for CA2
    #######################
    1. runmqckm -keydb -create -db CA2 -pw Passw0rd -type cms -expire 365 -stash

    Create Self Signed CA2’s Root Certificate
    ######################################
    2. runmqckm -cert -create -db CA2.kdb -pw Passw0rd -label ssl_ca2 -dn “CN=Certificate Authority (CA2),O=IBM India,C=IN” -expire 365

    Extract Root Certificate
    #######################
    3. runmqckm -cert -extract -db CA2.kdb -pw Passw0rd -label ssl_ca2 -target ssl_ca2.cer -format ascii

  2. Create & Connect Qmgrs

    In this section, we have created the 3 Qmgrs (ORG_A, ORG_B & ORG_C) & established distributed connectivity between ORG_A <==> ORG_B & ORG_A <==> ORG_C as shown in the below screenshot. Make sure that all the Channels are working fine.

    Note: The Creation of Qmgrs & its associated configurations are not shown in this article.

    1-5

  3. Generate CSR files

    1. Create the keystores for the 3 Qmgrs ORG_A, ORG_B & ORG_C using ikeyman utility (Same process like CA1 & CA2 as mentioned in Section 1).

    2. Generate the Certificate Signing Request (CSR) file for the Qmgr ORG_A to be signed by CA1 as shown in the below screenshot. Note that from MQ v8 onwards, there is no mandatory requirement to follow the Cert Key Label naming convention i.e. ibmwebspheremq<Qmgr Name in Lower Case>. You have the flexibility to choose your own cert label which was not the case in previous versions of MQ.

    6-3

    3. Similarly, generate the Certificate Signing Request (CSR) file for the Qmgr ORG_A to be signed by CA2 as shown in the below screenshot.

    12

    4. Repeat the same steps of generating the CSR file for the Qmgr ORG_B to be signed by CA1.

    5. Follow the same steps of generating the CSR file for the Qmgr ORG_C to be signed by CA2.

  4. Sign the CSR files

    In this section, we are going to digitally sign the CSR files of ORG_A & ORG_B Qmgrs using CA1. The target files are named as orga_ca1.cer & orgb_ca1.ser as shown in the below screenshot.

    8-3

    On Windows platform, these Signed CSR files signed by CA1 will look like this!

    9-3

    Similarly, digitally sign the CSR files of ORG_A & ORG_C Qmgrs using CA2. The target files are named as orga_ca2.cer & orgc_ca2.ser as shown in the below screenshot.

    8a

    On Windows platform, these Signed CSR files signed by CA2 will look like this!

    9a

  5. Add & Receive the Signed Certs

    1. Once the CSR files has been Signed by respective Certificate Authorities, transfer back the Signed Certs along with the Public Certs of the Certificate Authorities into respective Qmgr’s keystore directory as shown below. Since ORG_A Qmgr have Certs signed by both CA1 & CA2, we have 1 pair of CA’s Public Certs & 1 pair of CSR Sgined Certs marked in red in the below screenshot.

    24

    2. In this Steps, we need to Add the Public Certs of the Certificate Authorities into respective Qmgrs’s keystore & Receive the digitally Signed Cert into the Qmgr’s keystore as well using the below commands:

    Add Public Certs of CA1 & CA2

    ###########################

    runmqckm -cert -add -db org_a.kdb -pw Passw0rd -label ssl_ca1 -file ssl_ca1.arm -format ascii -trust enable

    runmqckm -cert -add -db org_a.kdb -pw Passw0rd -label ssl_ca2 -file ssl_ca2.arm -format ascii -trust enable

    Receive the Signed Certs by CA1 & CA2

    ###################################

    runmqckm -cert -receive -db org_a.kdb -pw Passw0rd -file orga_ca1.cer -format ascii

    runmqckm -cert -receive -db org_a.kdb -pw Passw0rd -file orga_ca2.cer -format ascii

    3. As part of validation step, list the Certs in Qmgr ORG_A’s keystore repository as shown below. There will be total 4 Certs for the Qmgr ORG_A, 2 Public Certs of CAs & 2 Signed Certs by CAs.

    13

    4. Repeat Steps 1-3 for the other 2 Qmgrs i.e. ORG_B & ORG_C.

    5. List the Certs in Qmgr ORG_B’s keystore repository as shown below. There will be 2 Certs for the Qmgr ORG_B.

    14-1

    6. List the Certs in Qmgr ORG_C’s keystore repository as shown below. There will be 2 Certs for the Qmgr ORG_C.

    15-1

  6. Set SSLKEYR & CERTLABL

    Alter the Qmgr’s SSLKEYR parameter to point to correct keystore file location & name WITHOUT the .kdb extension as shown in the below screenshot for 3 Qmgrs.

    17-1

    There is a new Parameter called CERTLABL introduced in MQ v8.0 onwards. Using this field, we can isolate the various CA Signed Certs to be used by multiple MQ Channels connecting to other Qmgrs. In this case, Qmgr ORG_A is connecting to ORG_B & ORG_C using CA1 & CA2. Hence, the CERTLABL being used by SDR / RCVR Channels ORG_A.TO.ORG_B & ORG_A.TO.ORG_C are orga_cert_ca1 & orga_cert_ca2 respectively.

    19-1

    The CERTLABL settings on the ORG_B should be set only at the Qmgr level only as shown below. The Channels will take the Certificate name details from the Qmgr level CERTLABL parameter. Hence, CERTLABL is kept BLANK in the Channel definitions.

    20

    Same settings as Qmgr ORG_B is applicable for the Qmgr ORG_C as well.

    21

  7. Set SSL Cipher Spec

    Finally, set the same SSLCIPH algorithm on the SDR / RCVR Channels between Qmgrs ORG_A & ORG_B.

    22

     And set the same SSLCIPH algorithm on the SDR / RCVR Channels between Qmgrs ORG_A & ORG_C.

    23

  8. Start the Channels

    Finally, issue the Refresh Security Command on all 3 Qmgrs & Start the SDR / RCVR Channels.

    runmqsc ORG_A,B,C

    ##################

    REFRESH SECURITY TYPE(SSL)

    The below screenshot shows TLS enabled MQ Channels are running using Certificates from 2 different Certificte Authorities i.e. CA1 & CA2.

    ORG_A <===========> ORG_B  &&  ORG_A <===========> ORG_C

                               CA1                                                                 CA2

    18-1

    Observer the output from Qmgr ORG_B.

    25

    Observer the output from Qmgr ORG_C.

    26

  9. Conclusion

    Thus, we have demonstrated in this article that using IBM® MQ v8.0, a single Qmgr can use Certficates signed by multiple CAs & simultaneously connect to one or more Business Partner’s Qmgrs which was not possible in versions prior to MQ v8.0. There are two major changes in the new version viz. the Cert Lable Name does not need to follow the strict naming convention of ibmwebsphere<Qmgr Name in Lower Case> & the introduction of the new parameter called CERTLABL at both Qmgr & Channel level. Using this new field, we have the option to specify the different Certificate names to be used by each MQ Channels for a given Qmgr while connecting to other Organization’s Qmgrs having different CA requirements.

    Additionaly, you can also refer my other tech. articles on IBM® MQ:

    1. End to End Message Security

    2. Advanced Clustering Techniques using IBM MQ

    3. Working with IBM® MQ Managed File Transfer (MQMFT)…

    4. IBM® MQ, an Enterprise Messaging Backbone in a True Sense!

  10. Related Topics

    1. End to End Message Security using IBM MQ

    2. https://www.slideshare.net/IBMWebSphereUK/201407-mqm01-whats-new-in-mq-v8

    3. http://www-01.ibm.com/support/docview.wss?uid=swg21578742

    4. How does MQ provide multiple certificates (CERTLABL) ?

    5. Download IBM MQ trial version

     

Join The Discussion