PKI (SSL) connection setup of client MQ and IIB tooling - Rfhutil

 

This series of walk-throughs is intended to provide some guidance to developers to set up their client tooling connections, by means of example, where PKI (public key infrastructure) is employed with MQ and IIB endpoints.

PKI is generally used to distinguish an SSL infrastructure from an environment where self-signed certificates are employed as personal certificates. Self-signed certificates are a quick and easy way for a developer to practice with some of the SSL aspects of their code, but are not recommended for a full Development environment and certainly not for Production. Why would one employ PKI in a Development environment? The simple answer is that there are differences and the sooner those differences are got to grips with in the development cycle the more rapid and successful the adoption of PKI will be. Following that preamble, I should add that the details of how to build and manage PKI are detailed elsewhere. (Management being far more the trickier of the two.)

Having said that, in what follows, there are only a few differences to the approaches that are adopted with a self-signed certificate infrastructure.

Certain assumptions are made in the following:

-          Authorisation in IIB is provided through MQ authorisations via MQ profiles. The details of this can be found in the IIB KC (Knowledge Center), and is outside the scope of this article.

-          You have already created the appropriate authorisations, channel authorisation records and AUTHINFO connection details needed to the queue manager. (I will no doubt cover this elsewhere in a future article.)

-          The sample choices of ciphers are representative of industry options, taking into account limitations of the given client tooling.

-          The ciphers, were possible or practicable, are chosen to be AES256 – i.e. strong encryption.

Setting up Rfhutic

Rfhutil is a popular development test tool, as it is versatile and relatively straight forward to use. For client connectivity, it ships an executable called rfhutilc.exe. Having said that, it is, along with a number of other client tooling options at this time, Rfhutil is yet making early forays into the world of PKI (which seems to be rapidly changing all the time, largely due to the discovery of security vulnerabilities). As such, it has some limitations.

-          At the time of writing, mutual authentication with Rfhutil is not possible

-          The CipherSpecs can only be chosen from a drop down menu (which obscures the full details of many of the ciphers).

-          You may discover more!

Rfhutil is written in C and consequently requires the use of a single CMS key store for both signer and personal certificates, together with the private key (as is the case for MQ C clients). Similar to a queue manager itself, a password is not provided to Rfhutilc for the key store, but rather a stash file (for example, the *.sth file below).

Firstly, in order for rfhutilc to work you will minimally need to have the MQ client code installed locally and the latest copy of Rfhutil. Assuming this,

1)    In the Queue Manager Name field, enter the name of the SVRCONN channel, e.g. CORP.RFHUTIL.SVRCONN, the server and port number in the format:

CORP.RFHUTIL.SVRCONN/TCP/anmqserver.com(port), as in the example below.

2)    Click on the Set Conn Id radio button.

3)    In the Set Connection Parameters panel that pops up, set the user ID and password (thes should be the credentials that you use to log onto the remote server with). Then set the CSP checkbox.

4)    You will need to copy your CMS key store files, similar to the below, to a suitable directory and edit the Certificate Store Location setting in the Set Conn Id panel.

5)    In addition, check the SSL checkbox and choose cipher TLS_RSA_WITH_AES_256_CBC_SHA, for example. Note that, you will only be able to see the first part of this cipher (an rfhutil bug, as mentioned above) but you should be able to see enough to distinguish this cipher from the others. This cipher should match that specified on the SVRCONN being used on the connection.

6)    Click OK then try Load Names to verify your connectivity.