You are currently browsing the category archive for the ‘security’ category.
I’ve posted before about setting up WebSphere MQ Explorer as a read-only viewer using setmqaut and MCAUSER ids – a post which has proved quite useful to some readers.
A similar topic which seems to raise questions is using WebSphere MQ Explorer to administer remote queue managers where all server-connection channels are secured using SSL/TLS.
In this post, I will give some background about the issues surrounding using WMQ Explorer with SSL, and outline how it can be used with multiple queue managers.
Emir Gaza (Consulting IT Specialist, Hursley Software Lab Services) and I are currently putting together a list of SSL gotchas based on our personal experiences and, of course, those of our customers. Our list covers many problems and solutions already well documented in the manuals (e.g. Error messages), but what we’re trying to do is compile a single list containing both common problems and those with sometimes cryptic solutions.
We aim to expand this list in future with more items and more detail, but for now, here’s the list we have compiled… Comments most welcome…
Here is a minimalist cookbook for getting SSL working with XMS .NET client when communicating with WebSphere MQ*. Comments and suggestions are very welcome!
* Understanding of basic JMS and XMS concepts is assumed in this cookbook. For further information about JMS, see ‘Using Java’ book and for further information about XMS see ‘Message Service Clients for C/C++ and .NET’ book shipped with XMS.
- Currently, MQ SSL only applies to the unmanaged client*. This functionality is not available for the fully managed client (which is the default). This functionality is not applicable for the bindings mode, as there is no network communication in bindings.
- The following only applies to MQ v6, as v5.3 has a different SSL story, at-least for Windows, I think.
So, in source code we must do the following:
* XMS .NET for WebSphere MQ delegates the security to lower layer of ‘MQ classes for .NET’. ‘MQ classes for .NET’ supports three connection modes – unmanaged client, fully managed client and bindings. XMS .NET transparently allows a selection between these three connection modes thru the XMSC.WMQ_CONNECTION_MODE property on a ConnectionFactory. For further information about these modes, see ‘Using .NET’ book. However, in a nutshell: unmanaged client is .NET wrapper with underlying C library, fully managed client is 100% pure .NET and bindings is (by definition) unmanaged, since it does IPC with the queue manager processes. (client modes communicate over network, bindings mode does IPC).
SSL channels for WebSphere MQ provide an excellent way to protect messages as they move from one queue manager to another. However, how can you protect messages when they are at rest on a queue? Also, how can you tell if the message has been altered since it reached the queue and how do you know who really sent the message?
WebSphere MQ Extended Security Edition can be used to solve these problems and more. It employs a certificate based security infrastructure which provides authentication, authorisation and auditing for a WMQ network. This means messages can be digitally signed and/or encrypted for their entire lifetime inside WMQ. WMQ ESE also provides authentication of users and their authorisation to queues and messages. WMQ ESE is administered centrally for easy to manage end to end security.
For more information on WMQ ESE, checkout the product page here.
If there is a good amount of interest in this topic then I’ll follow up with some more articles on how to implement and make best use of WMQ ESE
Most discussions on using SSL with WMQ Java applications (using the WMQ Classes for Java) talk about using the javax.net.ssl.keyStore etc. Java System Properties to specify a certificate store and password.
This works well for most applications.
However, there are a few limitations to this approach:
- The SSL context is initialised only once – the first time it is used.
If the path/password is incorrect, the JVM must be terminated before trying again.
- Debugging is only available through using javax.net.debug system property.
This produces a large amount of output on the console.
- Only one certificate store can be used per JVM.
You might want to use different certificates to connect to different queue managers.
So, this post has the starting point for an alternative.
SSL certificates are stored in SSL key repositories. The SSLKEYR attribute of the queue manager identifies which key repository to use – giving the path of the key repository file. But the key repository can hold several certificates, so we identify which certificate to use for which queue manager or client using the certificates’ label names.
For queue managers, the certificate label name should be
ibmwebspheremq with the queue manager name (converted to lower-case) appended.
For clients, the certificate label name should be
ibmwebspheremq with the name of the user who runs the client (converted to lower-case) appended.
There we go – easy. Except that’s not all there is to it. There is an exception. This post is a discussion of that exception, how it came to happen, and a discussion on whether it’s a good idea or not.
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.
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.