IBM Websphere MQ - Verifying Queue Managers SSL Configuration with MQCERTCK - Middleware News

Verifying  Queue Managers SSL Configuration with MQCERTCK. Tweet MQCERTCK is the updated version of the MH03 SupportPac that is now included in MQ as of version 8.0.0.4. MQCERTCK is a tool to look for common mistakes in your Queue Manager’s SSL configuration and provides recommendations for resolving problems. It will check: Existence and permissions of Queue Manager’s Key Repository referenced in the Queue Manager SSLKEYR attribute Existence and validity of Queue Manager’s certificate referenced in the Queue Manager CERTLABL attribute. Existence and validity of any certificates referenced in SSL enabled channel’s CERTLABL attributes. Client applications key repository and certificates, including checking the certificates are authorised with the Queue Manager. It is available on all Distributed platforms and the MQ Appliance but is not available currently on z/OS or IBMi, additionally the messages written out by MQCERTCK are available in English only. Usage In order to use the new MQCERTCK tool execute “mqcertck” with its required parameters using a command line which has been configured with the MQ v8.0.0.4 environment. MQCERTCK takes the following parameters: mqcertck -clientkeyr -clientchannel -clientusername -clientlabel -clientport Where: Parameter Usage Notes Description QMName Required The Name of the Queue Manager which you are running MQCERTCK against. Client Key Repository Optional The location of the client key repository that clients will use to connect to the Queue Manager. Channel Name Optional, requires –clientkeyr The name of the channel that the client will be connecting to. Client Username Optional, requires              –clientkeyr, cannot be supplied with -clientlabel The user name that will be running the client application if a client certificate label value will not be supplied. Client Certificate Label Optional, requires             –clientkeyr, cannot be supplied with                      –clientusername The client certificate label that client applications will use in the SSL connection. Free Port Number Optional, requires –clientkeyr, Default: 5857 A free Port that MQCERTCK can use during its tests. See Verifying Client Connections later in this blog for more information. Since no additional software, such as user-applications, can be run on the IBM MQ Appliance, the –clientkeyr, -clientchannel, -clientusername, -clientlabel and –clientport parameters and associated functionality are not available when running MQCERTCK on the MQ Appliance. Example Usage Alice has just finished setting up her Queue Manager QM1 to allow SSL Connections from clients connecting to its SVRCONN channel. Alice is using the new multiple certificates feature and so both her Queue Manager and Channel have a Certificate label specified in their CERTLABL attributes. While creating the channel Alice has made a mistake in her Channel’s CERTLABL attribute and so when a client attempts to connect the Queue Manager will return a 2393 MQRC_SSL_INITIALIZATION_ERROR. Before making the Queue Manager live, Alice decides to use the MQCERTCK tool to verify her Queue Manager’s SSL Configuration, she executes: mqcertck QM1 MQCERTCK shows the error message: 5724-H72 (C) Copyright IBM Corp. 1994, 2015. +---------------------------------------------------------- | IBM MQ TLS Configuration Test tool +---------------------------------------------------------- | Problem identified: |  No certificate could be found for the channel |  CLIENT.CONNECTION | |  This tool looked in the Queue Manager's key repository |  located at: 'C:\MQ Data\qmgrs\QM1\ssl\key.kdb' |  for a certificate with label 'chacert', |  which is the certificate specified in the channel's |  CERTLABL attribute, but was unable to find one. | | Possible resolution: |  A valid certificate with the label chacert |  needs to be added to the key repository. | |  Alternatively, alter the channel definition to remove |  the CERTLABL value. This can be done by executing the |  following command in runmqsc: |      ALTER CHANNEL() CHLTYPE() CERTLABL(' ') +---------------------------------------------------------- | mqcertck has ended. See above for any problems found. | If there are problems then resolve these and run this | tool again. | +----------------------------------------------------------  Which prompts Alice to check her Channel Definition for the CLIENT.CONNECTION channel, here she is able to see the error she made and quickly connect it before running MQCERTCK again to verify the problem has been resolved. Verifying Client Connections Since no additional software, such as user-applications, can be run on the IBM MQ Appliance, the following MQCERTCK feature is not available on the IBM MQ Appliance MQCERTCK has the ability to verify client key repositories as well as the Queue Manager’s SSL Configuration. To do this MQCERTCK needs to be able to access the Client’s key repository from the machine running the Queue Manager. When running MQCERTCK if you supply the –clientkeyr parameter with the location of the client key repository (excluding the extension) MQCERTCK will check this key repository against the Queue Manager. If you know which channel the client will be connecting to the Queue Manager via you can specify this with the –clientchannel flag. If the client will be using mutual authentication to connect to the Queue Manager you can use the  –clientusername or –clientlabel parameter to tell MQCERTCK which certificate to use in the client key repository. If you are using the default certificate and not supplying a certificate label to the client application then you can use –clientusername and the username which will run the application, during MQCERTCK’s operation it will generate the certificate label “ibmwebspheremqXXXX” where XXXX is the value passed in the –clientusername parameter. In order to fully verify the client key repository MQCERTCK will create a dummy connection using GSKit. To do this it needs to have a port available that it can bind to during its client tests. The default port used is 5857 however if this is already in use then you can specify a different port to be used during the client tests. Although MQCERTCK will bind to a port, no external communications will be used by MQCERTCK and all tests will be performed locally.