IBM MQ Solution Designer Certification

O ya. I almost forgot to post my status on the IBM MQ certification test number 996.

Compared to the SOA certification I previously taken, which I commented most of the questions are very subjective to different minds, MQ exam is straighforward and technical indeed. Maybe one or two questions are abit gray because of the way they phrased the statements, the rest are the kind either you know or you don't know because you didn't study.



I think this paper is not a big problem for professionals who got extensive designing and solutioning experience (like me!). Another certification paper on MQ administration should provide more comprehensive coverages on how MQ really in action operationally.

Using SHA-1 as message digest algorithm instead of MD5

In the light of a comment dropped by T.Rob in my previous post "A First Look at using MQ with SSL", I did some rough browsings about MD5 vulnerabilities and would like to share some of the links here.

Tim Callan's SSL Blog

SearchSecurity - VeriSign addresses MD5 flaws

Wiki - MD5

MD5 considered harmful today

The truth about the new attack on MD5 signatures

I guess for development purposes, it's ok for using MD5 based finger print/digital signature. We should now avoid using MD5 to perform critical application level hashing to prevent potential security issues. SHA-1 apparently is a better choice now even though it is theoretically vulnerable to the same issue albeit requires more significant processing power to do the trick.

Note that iKeyMan GUI, runmqckm (MQ 6.0) and Java keytool program uses MD5 as default signing algorithm.

For Java keytool, you can use the -sigalg SHA1withRSA option to override the default.

For strmqikm and runmqckm (MQ 7.0 uses sha1 by default, check here ), you can use GSKCapiCmd instead because it allows the specification of -sigalg sha1 to use SHA-1 algorithm


There's another way I found from the comments:

Option B is to acquire any IBM Java 6 JRE, add the IBMCMSKS provider to
java.security, and use the bundled ikeycmd or your /bin/gsk7cmd with
JAVA_HOME pointing at the new JRE -- sig_alg will be accepted there as well.

--
Eric Covener

MustGather information for Certificate problems

The following page provides useful information to diagnose problems with digital certificates.

http://publib.boulder.ibm.com/httpserv/ihsdiag/gather_certificate_doc.html#PKCS12

A First Look on using MQ with SSL

Secure Sockets Layer (SSL) technology is meant to provide a standardized solution to many security services such and authentication, confidentiality and integrity. Almost all distributed technology products nowdays comes with built-in SSL support. To name a few, IBM WAS, Apache Tomcat, Internet Explorer/Firefox and etc. Even sophisticated operating systems like i5/OS and z/OS has SSL integrated into the core.

The good thing about learning SSL is because SSL is one layer above TCP/IP (The transport protocol stacks) and below application layers such as HTTP, FTP, SMTP and blah, the concept is easily brings into new context.

I won't go deep into the major technical details of SSL in this post (maybe will do it in future posts), but there are a few jargons we need to share a common understanding. More information about these stuffs can be found in WIKI.

Certification Authority (CA) : A party designated to sign/issue digital certificates. Commercial CA such as Verisign.

Certification Revocation List (CRL): A list that stores the revoked/cancelled certificates

Digital Signature : A piece of information encrypted by the sender's private key.

Digital Certificate : A structure that complies to standards such as X.509 and includes also a digital signature

Certification Chain : A tree like relationship between signer CA, intermediate CA and ultimately the owner of the digital certificate.

Symmetrical Crytography : A branch of crytography focusing on shared keys.

Asymmetrical Crytography : A branch of crytography using non-shared keys to avoid key distribution issues.

SSL Handshake : A process in SSL protocol to establish SSL communications between SSL client and SSL server which includes negotiating algorithms, exchanging keys and encrypting messages.

SSL Key Store/Key Ring/Key Repository : A storage medium (usually a physical file) that keeps keys and certificates. Usually a password is needed to open the medium.

And many more terms as you delve into the realm.

I will assume the use of IBM Webpshere MQ6.0 and Windows XP.

---

In IBM Websphere MQ, SSL is only used during client mode communication. Bindings are direct and not involving SSL. More precisely, SSL can be configured for message channels and MQI channels. Message channels are meant for queue mangers (QMs)intercommunications and MQI channels are for MQ clients interaction with QMs.

Note: SSL is not used for access control purposes. In MQ, if you need to perform authorization checks, you might need to implement something called exits.

I will configure the following settings to demonstrate the usage of SSL for message channels (For MQI channels, it will be a future post by itself):

* 2 Queue Managers
* QM communications using Sender-Receiver channel pairs.
* 2 properly configured keystores, one for each of the QM.

The steps are:

1. Creating MQ QMs


2. Creating Key Stores


3. Creating Self Signed Certificates


4. Exchanging Certificates


5. Configuring QM


6. Creating and Configuring channels and listeners


7. Test out SSL connections

---

Assume %MQ_INSTALL_PATH% = C:\Program Files\IBM\Websphere MQ\

1. Creating MQ QMs
   
   Create 2 queue managers with name qm1 and qm2
   
   
   
   
   
   
2. Creating Key Stores
   
   I will be using GSKit iKeyMan utility that comes with Websphere MQ. Otherwise you might want to use other similar tools such as OpenSSL. The keystore format is CMS and their file name is ended with a .kdb extension.
   
   Command line version of iKeyMan is iKeyCmd (runmqckm)
   
   To run iKeyMan, proceed to command prompt and execute
   
   

   
   STRMQIKM
   

   
   
   
   
   
   
   
   
   
   
   Then choose from the menu bar [Key Database File] -> [New]
   
   Select [CMS] as the type, enter "qm1.kdb" as the file name as specify C:\ as the location for this example.
   
   
   
   You are required to key the key store password to protect your key store and you must tick the [Stash the password to a file?] option.
   
   The screen will looks like below once the keystore is successfully created and you can see that the iKeyMan preloaded some trusted CA certificates for you.
   
   
   
   
   As one of the best practice, you should remove all the preloaded certificates and remain only those necessary to prevent potential security issues.
   
   Repeat the above procedure for qm2's keystore with [CMS] type, "qm2.kdb" name and C:\ location.
   
   I recommend you to open another instance of iKeyMan (strmqikm) to avoid confusion when switching between key stores.
   
   


3. Creating Self Signed Certificates
   
   While you opened qm1.kdb in iKeyMan, from the [Key Database Content] filter, select [Personal Certificates], see below:
   
   
   
   Click on the [New Self Signed] button at right hand side and fill in the form like the screen below:
   
   
   
   In Windows platform, MQ will use the key label to identify which certificate to be used to authenticate a queue manager.
   
   The key label must be prefixed with "ibmwebspheremq" and then concatenated with the queue manager name, in this example "qm1", all in lower case. Here the key label is "ibmwebspheremqqm1".
   
   Repeat this step for qm2.kdb keystore but with the key label "ibmwebspheremqqm2".
   
   
   


4. Exchanging Certificates
   
   In the same screen, select [Extract Certificate] button.
   
   
   
   
   
   For ibmwebspheremqqm1 certificate, extract it to C:\qm1.arm
   For ibmwebspheremqqm2 certificate, extract it to C:\qm2.arm
   
   
   For qm1 keystore, import C:\qm2.arm by selecting [Signer Certificate] from the [Key Database Content] drop down and click [Add]. Specify "qm1.kdb" and C:\ as the location and when you click [Ok], a [Enter a label] message will prompt you to specify a label for the to-be imported signer. Enter "ibmwebspheremqqm2" and press [OK]
   
   
   
   The qm2 certificate will appear as one of the signer in the list.
   
   
   
   By now, your settings should be:
   
   

   
   -qm1.kdb (Keystore for Queue Manager qm1)
   --ibmwebspheremqqm1 (Personal Certificate for qm1)
   --ibmwebspheremqqm2 (Signer Certificate for qm2)
   
   -qm2.kdb (Keystore for Queue Manager qm2)
   --ibmwebspheremqqm1 (Signer Certificate for qm1)
   --ibmwebspheremqqm2 (Personal Certificate for qm2)
   

   
   
   


5. Configuring QM
   
   I will use RUNMQSC command line utility to perform most of the configuration. Of course, you can use MQ Explorer.
   
   Execute
   
   

   
   STRMQM qm1
   STRMQM qm2
   

   
   
   to start both of the QMs.
   
   
   
   Execute
   
   

   
   RUNMQSC
   

   
   
   to enter MQSC interactive session for qm1.
   
   Check out the current SSLKEYR attribute by executing
   
   

   
   DIS QMGR SSLKEYR
   

   
   
   
   
   By default, the value should be C:\PROGRAM FILES\IBM\WEBSPHERE MQ\QMGRS\qm1\ssl\key
   
   We will change it to point to our qm1.kdb.
   
   Exexcute
   
   

   
   ALTER QMGR SSLKEYR('C:\qm1')
   

   
   
   

   
   Note: Do not include the .kdb extension in the value of SSLKEYR.
   

   
   
   
   
   

   
   Note: I recommend you to open another instance of command prompt to work with qm2.
   

   
   
   
   Repeat this step on qm2.
   
   

   
   RUNMQSC qm2
   DIS QMGR SSLKEYR SSLEV
   ALTER QMGR SSLKEYR('c:\qm2') SSLEV(ENABLED)
   DIS QMGR SSLKEYR SSLEV
   END
   

   
   
   


6. Creating and Configuring channels and listeners
   
   Execute commands below for qm1.
   
   

   
   DEFINE QLOCAL('qm2') USAGE(XMITQ) TRIGGER INITQ(SYSTEM.CHANNEL.INITQ) TRIGDATA('TO.qm2')
   
   DEFINE LISTENER('LISTENER.TCP') TRPTYPE(TCP) PORT(10001)
   DEFINE CHANNEL('TO.qm1') CHLTYPE(RCVR) SSLCIPH(RC4_SHA_US)
   DEFINE CHANNEL('TO.qm2') CHLTYPE(SDR) CONNAME('localhost(10002)') SSLCIPH(RC4_SHA_US) XMITQ('qm2')
   
   START LISTENER('LISTENER.TCP')
   REFRESH SECURITY TYPE(SSL)
   

   
   
   
   Execute commands below for qm2.
   
   

   
   DEFINE QLOCAL('qm1') USAGE(XMITQ) TRIGGER INITQ(SYSTEM.CHANNEL.INITQ) TRIGDATA('TO.qm1')
   
   DEFINE LISTENER('LISTENER.TCP') TRPTYPE(TCP) PORT(10002)
   DEFINE CHANNEL('TO.qm2') CHLTYPE(RCVR) SSLCIPH(RC4_SHA_US)
   DEFINE CHANNEL('TO.qm1') CHLTYPE(SDR) CONNAME('localhost(10001)') SSLCIPH(RC4_SHA_US) XMITQ('qm1')
   
   START LISTENER('LISTENER.TCP')
   REFRESH SECURITY TYPE(SSL)
   

   
   
   


7. Test out SSL connections
   
   You can now test the connection by starting sender channel in each queue manager manually.
   
   To do this in qm1, execute the following:
   
   

   
   START CHANNEL('TO.qm2')
   DIS CHSTATUS('TO.qm2')
   

   
   
   To do this in qm2, execute the following:
   
   

   
   START CHANNEL('TO.qm1')
   DIS CHANNEL('TO.qm1')
   

   
   
   If the channel communications are successful, you will get screen similar to the one below:
   
   
   
   Pay particular attentions to the attributes
   
   

   
   STATUS=RUNNING
   SSLPEER=
   SSLCERTI=
   

   
   
   

   
   Note: If you need to change any of the SSL related attributes like key store location and channel SSL settings, remember to issue the following command:
   

   
   
   

   
   REFRESH SECURITY TYPE(SSL)
   

   
   
   

   
   Note: To troubleshooting problems, you can check out the QM error logs located at %MQ_INSTALL_PATH%\QMgrs\qm1\errors\