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.

.

Making client connections

Let me start with a little background. To use WMQ Explorer with a remote queue manager, you create a client connection in WMQ Explorer to a server connection channel on the queue manager.

You can do this manually by putting the hostname and server-connection channel name in the Add Queue Manager wizard.

Alternatively, if you need to specify more information you can use a client channel definition table (CCDT) : creating a client channel on a queue manager (specifying values for all the different attributes) and using the file it creates as the source of a channel definition.

If you want to use SSL, then you need to use some of the client channel SSL parameters (such as to identify an SSL Cipher Specification to use, matching the spec on both client and server ends of the channel). This means you need to use a CCDT to specify a connection for WMQ Explorer.

Connections to multiple queue managers

When using a WMQ Explorer to administer multiple queue managers on multiple remote servers, there are a number of general approaches, including:

• use a single CCDT file

  typically a single queue manager on a development machine is used to create several client connection channels - one to each of the queue managers to be administered with the WMQ Explorer. The single CCDT file created by that queue manager can be transferred to the system running the WMQ Explorer and used to define the connections to all remote queue managers.

• use multiple CCDT files

  creating both server and client connection channels on each remote queue manager to be administered with WMQ Explorer, and using each of the CCDT files from them all.

Either way, WebSphere MQ Explorer does not store the client channel definition information itself, so it is important that a permament location for the CCDT file(s) is found before identifying a file to WMQ Explorer.

.

Locating the SSL certificate repositories

Once the connection has been defined, the next step is to identify the repositories which will be used as the source of SSL certificates to authenticate the connection.

There are two main choices regarding authentication:

• Queue managers (servers) authenticate WMQ Explorer (client) only
  • set SSLCAUTH to OPTIONAL on the queue managers’ server-connection channel definition
• Queue managers (servers) authenticate WMQ Explorer (client), and WMQ Explorer authenticates queue managers
  • set SSLCAUTH to REQUIRED on the queue managers’ server-connection channel definition

.

Creating key repositories and certificates

It is outside the scope of this post to go into much detail about creating SSL certificates and repositories - but I have written about SSL before if more background is needed.

The only major difference to note for our purposes here is that (as a Java application) SSL certificate repositories created for use by WMQ Explorer must be a Java Key Store - .jks file.

If creating a new key repository, use -type jks if creating the keystore using GSkit at a command prompt.

If the key repository has already been created in a different format, it can be converted to JKS using GSkit’s -keydb -convert command.

.

Server authentication

Queue Managers authenticating a connection from WMQ Explorer

For server authentication only, the queue manager needs:

• The personal certificate issued to the queue manager by it’s CA (certificate authority)
• The queue manager’s private key

both of which will be contained in a key repository file (often key.kdb), identified by the queue manager’s SSLKEYR attribute.

.

WebSphere MQ Explorer needs:

• The CA (certificate authority) certificate for the queue manager’s CA, or the personal certificate issued to the queue manager by it’s CA

which should be stored in the key repository file (often key.jks), identified as the Trusted Certificate Store in the WMQ Explorer SSL Preferences.

.

Client authentication

WMQ Explorer authenticating a connection to a queue manager

For both server and client authentication, the queue manager needs:

• The personal certificate issued to the queue manager by it’s CA (certificate authority)
• The queue manager’s private key
• The CA (certificate authority) certificate for WMQ Explorer, or the personal certificate issued to WMQ Explorer by it’s CA

all of which will be contained in a key repository file (often key.kdb), identified by the queue manager’s SSLKEYR attribute.

.

WebSphere MQ Explorer needs:

• The personal certificate issued to WMQ Explorer by it’s CA (certificate authority)
• WMQ Explorer’s private key

which should be stored in the key repository file (often key.jks), identified as the Personal Certificate Store in the WMQ Explorer SSL Preferences.

WebSphere MQ Explorer also needs:

• The CA (certificate authority) certificate for the queue manager’s CA, or the personal certificate issued to the queue manager by it’s CA

which should be stored in the key repository file (often key.jks), identified as the Trusted Certificate Store in the WMQ Explorer SSL Preferences.

.

Notes:

1. In practice, both WMQ Explorer and the queue mangers might need other CA certificates to form a certificate chain to the root CA certificate. For more information about certificate chains, refer to How certificate chains work.
2. It is possible for both the Trusted and Personal Certificate Store preferences to point to the same actual key repository file. There is no harm in doing this provided that the security of the WMQ Explorer’s private key is maintained, however it is often clearer to maintain the separation between the two.

.

Connections to multiple queue managers

This should be relatively straightforward.

For server authentications, it requires the CA or personal certificate for each additional queue manager to be added to WMQ Explorer’s Trusted Certificate Store.

For client authentications, the WMQ Explorer’s CA or personal certificate also needs to be added to each additional queue manager’s key repository.

There should be no changes needed to the WMQ Explorer’s Personal Certificate Store between making an SSL connection to one or many queue managers.

Points to note

Wherever possible, it is helpful to establish a connection without SSL first before starting to apply security. This helps to rule out any non-SSL explanations if diagnosing a channel which will not connect.

There are a number of resources available to help diagnose SSL-related problems, some of which are outlined in an earlier post on SSL.

More information is available in Using the WebSphere MQ Explorer to connect to a remote queue manager using SSL enabled MQI channels.

---

Possibly related posts: (automatically generated)

• Using PowerShell with remote queue managers
• Internet Explorer 7-The first browser supports EV SSL Cirtificate.
• Recode queue design