Fix pack 11 introduces new configuration options for use by message flows which interact with IBM MQ queue managers using secured SSL client connections. Prior to this fix pack, when connecting to a secured MQ Server Connection channel, ACE looked within its designated keystore, and selected the key which had a label of the form ibmwebspheremqmyusername where myusername was the textual user identifier under which the integration server was running. Whilst fine for many users, this approach had some limitations for architectural topologies, such as forcing users to deploy message flows which need to run under different identities under different servers.
To take advantage of this new feature, examine the MQ Connection properties on the MQInput, MQOutput, MQGet and MQReply nodes. You will find a new property named SSL certificate label which can be used to select a specific SSL certificate from the integration server MQ key repository when using a SSL client channel to send or receive messages to a remote queue manager.
If you wish to abstract connection details away from the message flow node, you can use an MQ Endpoint policy, so the same property, named SSL certificate label has also been added to the MQ Endpoint policy as shown below:
When you configure an MQ connection from an MQ node to an IBM MQ queue manager, you can optionally configure the connection to use a security identity for authentication, SSL for confidentiality, or both. In the example that follows we will focus just on using SSL.
You can specify that the SSL protocol is to be used when a client connection is made to a remote queue manager, by selecting the Use SSL property on the MQ node or MQEndpoint policy. You can use SSL for client connections that are configured using either the MQ client connection properties or a client channel definition table (CCDT). If you specify SSL on the client connection, you must also specify the location of an SSL key repository which holds the required private and public certificates. The instructions below include commands to generate the certificates and also the SSL key repository password stash file, which is created in the same folder as the key repository itself.
To demonstrate this new ACE feature the example below describes how to set up mutual authentication between ACE and a queue manager using self-signed TLS certificates (for test purposes). This particular example assumes the use of Windows, although of course the commands could be amended for other platforms.
Create key repositories and certificates for both ACE and the queue manager:
- Create a key database for your queue manager from the command line, using the following command:
runmqakm -keydb -create -db C:\sslformyqm\key.kdb -pw myqmpassword -type cms -stash
This will generate the following files:
C:\sslformyqm\key.kdb
C:\sslformyqm\key.rdb
C:\sslformyqm\key.sth
- Create a key database for ACE (acting as an MQ Client application) from the command line, using the following command:
runmqakm -keydb -create -db C:\sslforace\key.kdb -pw acepassword -type cms -stash
This will generate the following files:
C:\sslforace\key.kdb
C:\sslforace\key.rdb
C:\sslforace\key.sth
- In this worked example, the queue manager we are using is named "MYQM". Folding this queue manager name to lower case and appending it to the fixed string "ibmwebspheremq" provides the required label when generating a personal self-signed certificate for use by the queue manager. Create the certificate in the key database from step 1, using this command:
runmqakm -cert -create -db C:\sslformyqm\key.kdb -pw myqmpassword -label ibmwebspheremqmyqm -dn "CN=MYQM, OU=Test, O=IBM, C=GB"
- Use this kind of command again to generate a personal self-signed certificate, but this time for use by ACE. Create the certificate in the key database from step 2, using this command:
runmqakm -cert -create -db C:\sslforace\key.kdb -pw acepassword -label ace1 -dn "CN=ACE1, OU=Test, O=IBM, C=GB"
- Extract the public part of the queue manager self-signed certificate:
runmqakm -cert -extract -db C:\sslformyqm\key.kdb -pw myqmpassword -label ibmwebspheremqmyqm -target C:\temp\myqmcert.cer -format ascii
- Extract the public part of the ACE self-signed certificate:
runmqakm -cert -extract -db C:\sslforace\key.kdb -pw acepassword -label ace1 -target C:\temp\acecert.cer -format ascii
- Add the public part of the queue manager self-signed certificate into the ACE key repository:
runmqakm -cert -add -db C:\sslforace\key.kdb -pw acepassword -label ibmwebspheremqmyqm -file C:\temp\myqmcert.cer -format ascii
- Add the public part of the ACE self-signed certificate into the queue manager key repository:
runmqakm -cert -add -db C:\sslformyqm\key.kdb -pw myqmpassword -label ace1 -file C:\temp\acecert.cer -format ascii
Defining the queue manager SSL configuration:
- Begin by creating and starting a queue manager. In this example we will be using a queue manager named MYQM:
crtmqm MYQM
strmqm MYQM
- Start an interactive runmqsc MYQM command session (the last command below defines a local queue named
IN which your ACE message flow will be reading input messages from):
ALTER QMGR SSLKEYR('C:\sslformyqm\key')
REFRESH SECURITY TYPE(SSL)
DEFINE LISTENER(MYLISTENER) TRPTYPE(TCP) PORT(4434)
START LISTENER(MYLISTENER)
DEFINE CHANNEL(ACE.TO.MYQM) CHLTYPE(SVRCONN) TRPTYPE(TCP) SSLCIPH(TLS_RSA_WITH_AES_128_CBC_SHA) SSLCAUTH(REQUIRED)
DEFINE QLOCAL(IN)
Defining the ACE SSL configuration:
- Point your integration node at the ACE key repository:
mqsichangeproperties ACEv110011 -o BrokerRegistry -n mqKeyRepository -v C:\sslforace\key
- Alternatively, if you prefer, you can achieve the same outcome through configuration in the node.conf.yaml file rather than executing the command above:
BrokerRegistry:
mqKeyRepository: 'C:\sslforace\key'
With this configuration now complete, you can deploy a message flow which takes advantage of the secured SSL MQ client connection which we just created!