WebSphere MQ supports the use of SSL to provide secure transmission of data, and administration of this is provided with the supplied tool GSkit.

Implementing this can be complicated, and with new users this tends to be due to difficulties with knowing what they want to achieve; or difficulties knowing which of the many similar-sounding GSKit verbs (e.g. import, add or receive) is appropriate for their uses.

In this post, I outline a few simple approaches to SSL administration and give GSKit script examples showing how they could be implemented.

Scope

I’m not going to cover the WebSphere MQ object definitions needed for an SSL environment. (It’s mainly just setting SSLKEYR on the queue manager and adding SSLCIPH to your channel definitions. It seems to be well documented elsewhere, but let me know in the comments if you think it would be worth covering it in more detail in a future post). Instead, I’ll cover the GSkit commands needed to create the certificates and SSL key repositories that your queue managers will need. Where possible, I’ll use terms consistent with the GSkit command terminology.

Quick introduction

Every queue manager has it’s own “key repository” for certificates. Certificates are labelled with ‘ibmwebspheremq’ followed by the name of the queue manager (or username for clients) in lower-case. When a connection attempt to a queue manager is made, the certificate provided by the remote queue manager or client needs to be validated against the contents of the queue manager’s own repository. The idea of this post is to explain a couple of approaches to doing this.

Everyone-knows-about-everyone-else

This is the simplest approach. Every queue manager has it’s own certificate in it’s own key repository. You then ‘extract’ the public part of this certificate, and give copies to every other queue manager for ‘add’-ing to their repositories.

This is straight-forward to start with - no need to mess about with signing certificates. When a connection attempt is made to a queue manager, the queue manager can authenticate the connection because it already has a copy of the public key for the certificate included in the connection attempt.

The downside is that it doesn’t scale very well with larger queue manager networks. Once you have lots of queue managers, it becomes an administrative nightmare. For example, every time you add a new queue manager to the network, you have to extract it’s certificate and add it to every other queue manager’s repository. Then you have to get copies of the certificates from every other queue manager’s repository, and add it to your new queue manager’s repository. If you have 100 queue managers, this would take a while and the potential for missing one is quite high.

Everyone-knows-one-trusted-person

The way to solve this problem is by using a ‘certificate authority’ (CA). Every queue manager has a copy of the public key of that certificate authority in it’s key repository, and every new queue manager’s certificate is signed by that CA.

This way, adding a new queue manager involves creating a new certificate and getting it signed by the CA. When a connection attempt is made to a queue manager, the queue manager can authenticate the connection because it can see that the certificate included in the connection attempt has been signed by a trusted signer already contained in it’s key repository.

This is a little more complex, but has the benefits of being scalable and easier to administrate in larger networks. There are a number of ways this can be implemented and two examples are provided (showing the flexibility in how the administration can be divided between different people):

  • certificate requests from CA repository
    The CA administrator creates a certificate and gives it to the queue manager administrator for ‘import’-ing into the queue manager key repository.
  • certificate requests from queue manager repository
    The queue manager administrator ‘create’s certificate requests identifying with the parameters (e.g. label) that they need, and then passes it to the CA administrator. The CA administrator then ’sign’s the certificate request, and returns it to the the queue manager administrator for ‘receive’-ing back into the queue manager key repository.

Note

The scripts provided are Windows batch files, but none of the concepts are Windows-specific. From WebSphere MQ v6, GSkit is the tool used for SSL administration on both Windows and UNIX platforms. The batch files could easily be converted into UNIX shell scripts by changing REM’s to #, %ENV_VARS% to $ENV_VARS, and the set’s to export’s.

Possibly related posts: (automatically generated)