This is an IBM Automation portal for Integration products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Search existing ideas
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updateson them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Specific links you will want to bookmark for future use
MQ Explorer: Implement access to Windows certificate and key store
In our installation, we have ~100 developers accessing our queue managers. We have the requirement to enforce certificate-based user authentication for all of them. The number of TLS and/or X.509 experts among them is limited. To reduce the support and management overhead on the one hand as well as to increase security on the other hand, our plan was to use an AD policy to automatically roll out dedicated client certificates to all our users' private Windows certificate stores. In addition to this, we planned to provide a configuration file which configures the Windows certificate store as the certificate and key source to be used by MQ Explorer.
According to IBM MQ support, however, MQ Explorer (currently) does not provide an interface to the Windows built-in certificate store. As a result, our certificate department now has to issue ~100 client certificates. Since these certificates have a limited expiry date, they (that is, the users as well as our CA guys) will have to go through the same procedure quite soon. The AD certificates, in contrast, would be renewed automatically.
As a hybrid approach, one could use the AD certificates and provide an export/import script to the users which copies the client certificate along with the associated private key as well as any potentially required additional intermediate or root CA certificate from the Windows certificate store to the (JKS) certificate and key store(s) used by MQ Explorer.
However, in addition to being error prone, this approach has two major security drawbacks. First, it requires the client certificate's private key to be marked as exportable in the Windows certificate store. Second, one has to rely on the users creating and/or leaving their certificate stores at a secure location and protecting them with strong passwords.
To our knowledge Eclipse-based MQ Explorer (9.2) is a Java application. According to the docs and our tests, Java basically offers built-in APIs to access the Windows certificate store. This is accomplished by setting the javax.net.ssl.trustStoreType and/or javax.net.ssl.trustStoreType system properties to WINDOWS-ROOT and/or WINDOWS-MY. These properties can be set by providing -D command line switches with appropriate arguments.
Our tests showed that these arguments may be coded after the -vmargs keyword in the MQExplorer.ini file and are then forwarded to the JVM. So basically, all that remains in a first step for a quick test is to make MQ Explorer honor these settings. Obviously, in a later stage, it would be great to have related options integrated into the GUI.
Do not place IBM confidential, company confidential, or personal information into any field.