http://www.wikio.fr WebSphere And Tivoli Tricks: Specifying the userid in the SSL certificate label for an MQ client

Monday, April 2, 2012

Specifying the userid in the SSL certificate label for an MQ client

Question

Does the standard WebSphere MQ SSL configuration require the personal certificates' label name with a special format as below?

WebSphere MQ Client: ibmwebspheremq + <User ID>
WebSphere MQ Server (queue manager): ibmwebspheremq + <QM Name>

Where the User ID or queue manager name must be folded to lower case in the label. For example, for a queue manager named QM1, the label is ibmwebspheremqqm1.

You want to know if you must comply with the rule for all of your MQ Clients, because you have many clients and it will be a big job to create unique certificates.
Cause

The original design and intent of MQ was that the answer to this question should be YES. It is still the intent that it is necessary to have a separate personal certificate with a label of 'ibmwebspheremq<username>' for each client connection. However, depending on what MQ maintenance level you are using, you may not see this working as designed in some circumstances. In certain scenarios, you may be able to get around the intended design.

Answer

The gsk6cmd command from GSKit provides -setdefault and -getdefault options to set or display a default certificate in a key repository. The behavior of this area of code has changed a few times, so here is a description of the expected behavior depending on your MQ maintenance level.

WebSphere MQ V5.3

    WebSphere MQ V5.3 CSD09 or earlier
    The default certificate will be used if: a default certificate is present, and there is no ibmwebspheremq certificate.
    This behavior was a defect which was corrected by APAR IC43762.
    WebSphere MQ V5.3 CSD10 through CSD12
    The default certificate will never be used. If you are at this level and require default certificate functionality, then you will need the fix for IC50156 and you must set the AMQ_SSL_ALLOW_DEFAULT_CERT environment variable, as described in IC50156 APAR text.
    WebSphere MQ V5.3 CSD13 and later
    The default certificate will only be used if the AMQ_SSL_ALLOW_DEFAULT_CERT environment variable is set, and the following conditions are both met: default certificate is present, and there is no ibmwebspheremq certificate

WebSphere MQ V6

    WebSphere MQ 6.0.0.0 through 6.0.1.1
    The default certificate will never be used. If you are at this level and require default certificate functionality, then you will need the fix for IC50156 and must set the AMQ_SSL_ALLOW_DEFAULT_CERT environment variable.
    WebSphere MQ 6.0.2.0 and later
    The default certificate will only be used if the AMQ_SSL_ALLOW_DEFAULT_CERT environment variable is set, and the following conditions are both met: default certificate is present, and there is no ibmwebspheremq certificate.

WebSphere MQ V7 & LATER Version

    WebSphere MQ 7.0.0.0 and later
    The default certificate will only be used if the AMQ_SSL_ALLOW_DEFAULT_CERT environment variable is set, and the following conditions are both met: default certificate is present, and there is no ibmwebspheremq certificate.


Notes:

1. All of the above holds true if you are using the MQ C client. If you are using MQ Java™ or MQ JMS clients the answer is NO, you do not need a unique certificate for every client userid. In the MQ Java and MQ JMS client environment the label is not used to do the certificate look up. However, a personal certificate for the queue manager end still needs a label of 'ibmwebspheremq<qmgrname>'.

2. The above information does not apply to platforms which do not use GSKit, such as z/OS for example or MQ v5.3 for Windows. MQ v6 for Windows does use GSkit, so the information is applicable on MQ V6 for Windows..

Warning:

Please note that the decision to remove default certificate support from WebSphere MQ was not made lightly, and was made for a number of security concerns. Although we have restored this in a limited way due to specific unique requests, this was not the functionality which we expected to see widely used. It is certainly not an approach which we recommend.

The administration of an SSL environment is something which we would advise you to consider carefully. Certificates are intended to provide a unique identification of a specific entity. The ability to establish a chain of trust from a trusted signer down to individual certificates allows for some of this administration to be delegated, however the use of default certificates makes it possible for far greater reuse and sharing of certificates to be achieved than is intended. In an extreme case, one default self-signed certificate could be used by every client and queue manager on a network, greatly increasing the risk of exposure to your network if the certificate becomes compromised.


If authentication of clients is not required, then you may find that setting SSLCAUTH to OPTIONAL in your channel definitions is a better solution for your needs. However, if authentication of clients is important, then you should consider whether wide reuse of a default certificate meets that need.

No comments:

Post a Comment