MQ

 View Only
  • 1.  MQ TLS Clients - which cert to send in a mTLS set up (SSLCAUTH=REQUIRED)

    IBM Champion
    Posted Mon March 20, 2023 02:36 PM

    I'm looking for a comprehensive description of what TLS/MQ Clients have to do to choose a TLS cert from their client side keystore when connecting to a queue manager SVRCONN channel with SSLCAUTH=REQUIRED.

    I found this page: https://www.ibm.com/docs/en/ibm-mq/9.2?topic=repository-digital-certificate-labels-understanding-requirements

    About 1/2 way down there is a section titled "Multiplatforms systems" with subsection "IBM MQ clients"

    For queue managers and clients respectively, the following sources are searched in sequence for a non-empty value. The first non-empty value determines the certificate label. The certificate label must exist in the key repository. If no matching certificate in the correct case and format is found that matches a label, an error occurs and the TLS handshake fails.

    1.Certificate label attribute CERTLABL in the CLNTCONN channel definition.
    2. MQSCO structure CertificateLabel attribute.
    3. Environment variable MQCERTLABL.
    4. Client .ini file (in its SSL section) CertificateLabel attribute
    5. A default, which is in the format: ibmwebspheremq with the user ID that the client application is running as appended, all in lowercase. For example, for a user ID of USER1, the default certificate label is ibmwebspheremquser1.

    Nowhere here does it say this only applies to C based MQ clients, but is that in fact true - does the above list only apply to C based clients and not Java/JMS?

    Because further down the page there is a section titled "IBM MQ Java and IBM MQ JMS clients" 
    Where it says:

    IBM MQ Java and IBM MQ JMS clients use the facilities of their Java Secure Socket Extension (JSSE) provider to select a personal certificate during the TLS handshake and are not therefore subject to certificate label requirements.

    The default behavior is that the JSSE client iterates through the certificates in the key repository, selecting the first acceptable personal certificate found. However, this behavior is only a default, and is dependent on the implementation of the JSSE provider.



    ------------------------------
    Peter Potkay
    ------------------------------


  • 2.  RE: MQ TLS Clients - which cert to send in a mTLS set up (SSLCAUTH=REQUIRED)

    IBM Champion
    Posted Mon March 20, 2023 02:49 PM

    Hi Peter,

    That list does not apply to Java/JMS clients. It only applies to KDB files and not JKS files.

    On the page you referenced, there is a note:

    1. You cannot set the certificate label yourself on Java or JMS systems.

    So Certificate label choices cannot apply.

    Also note that the mqclient.ini file CertificateLabel attribute is only use by C (and Managed .NET) clients as shown on this page.

    The certificate picked by a JSSE utilising client is not based on a label, but rather (if memory serves) based on what the queue manager sends. JSSE picks a certificate that it thinks is going to be able to be validated (I think that's what "the first acceptable personal certificate" in your quoted text means). That said, I'm not sure which certificate is picked is something that any JSSE provider has ever documented. I think this may be why the documentation is so sparse for Java clients - because the only sure fire way to know which certificate will be used is to only have one.

    Hopefully things have got better and someone out there can tell you the low down for Java. 

    Cheers,
    Morag



    ------------------------------
    Morag Hughson
    MQ Technical Education Specialist
    MQGem Software Limited
    Website: https://www.mqgem.com
    ------------------------------



  • 3.  RE: MQ TLS Clients - which cert to send in a mTLS set up (SSLCAUTH=REQUIRED)

    IBM Champion
    Posted Mon March 20, 2023 04:34 PM

    Thanks for confirming, Morag. You have to infer a lot from that page to have the complete story straight. They really should identify that section as applicable only to non Java/JMS implementations instead of assuming the reader reviewed the entire page - I mean really, who does that?  ;-)

    As it relates to what is or is not supported on a client implementation, Python, PyMQI - do you know if that is going to follow the rules for a C based implementation or Java/JMS one?



    ------------------------------
    Peter Potkay
    ------------------------------



  • 4.  RE: MQ TLS Clients - which cert to send in a mTLS set up (SSLCAUTH=REQUIRED)

    IBM Champion
    Posted Mon March 20, 2023 10:14 PM

    Hi Peter,

    PyMQI is based on the 'C' client (you can see the actual 'C' code here if you're interested). It ties itself to the 'C' client library mqic.lib by default, but you can instead change it to use the mqm.lib (see here for how). These are both the 'C' MQI libraries.

    So PyMQI will follow the 'C' MQI conventions. There is an example of using SSL/TLS with PyMQI here. You can see that it is using the MQSCO structure (mentioned in your list) and the MQCD structure. It would not be too difficult to extend this example to also use the CertificateLabel field in the MQSCO structure.

    Cheers,
    Morag



    ------------------------------
    Morag Hughson
    MQ Technical Education Specialist
    MQGem Software Limited
    Website: https://www.mqgem.com
    ------------------------------



  • 5.  RE: MQ TLS Clients - which cert to send in a mTLS set up (SSLCAUTH=REQUIRED)

    IBM Champion
    Posted Tue March 21, 2023 08:21 AM

    @peter & @Morag

    If memory serves, in Java you have the possibility to specify your own implementation of the SSLSocketFactory. This should allow you to determine a specific certificate for the queue manager client, if you need to have multiple personal certificates in your store. Hope this helps.



    ------------------------------
    Francois Brandelik
    ------------------------------



  • 6.  RE: MQ TLS Clients - which cert to send in a mTLS set up (SSLCAUTH=REQUIRED)

    IBM Champion
    Posted Tue March 21, 2023 09:55 AM

    Thank you Morag and Francois



    ------------------------------
    Peter Potkay
    ------------------------------



  • 7.  RE: MQ TLS Clients - which cert to send in a mTLS set up (SSLCAUTH=REQUIRED)

    Posted Tue March 21, 2023 10:29 AM

    You can have an IBM MQ Java/JMS client that uses a JKS that has multiple privateKeyEntry labels, and specify which label to use. I did not find it trivial to write. High level, you take the JKS that has the multiple privateKeyEntries, find the specific privateKeyEntry that matches some input label, and then programmatically build a virtual JKS that only has this one privateKeyEntry and the trustedCertEntries from the original JKS. Then you use this new JKS (which now only has one privateKeyEntry) as the one that is attached to your custom SSLSocketFactory.



    ------------------------------
    Tim Zielke
    ------------------------------



  • 8.  RE: MQ TLS Clients - which cert to send in a mTLS set up (SSLCAUTH=REQUIRED)

    IBM Champion
    Posted Wed March 22, 2023 08:54 AM

    With all the comments shared by other experts, below would allow you setup a working connection.

    Here the steps required from the client 

    • Get a Cert signed by CA. ( preferred to be same CA as the queue manager signed cert)
    • Client app builds a kdb ( if py) or jks ( java ) or just the cert and key ( node)
    • Label the cert in the keystore to any name.
    • if java; app can be started with extra jvm arguments passign the keystore and truststore ( -Djavax.net.ssl.keyStore=yyyy -Djavax.net.ssl.keyStorePassword=uuuu -Djavax.net.ssl.trustStore=cccc -Djavax.net.ssl.trustStorePassword=xxx
    • ensure the truststore has the Root and chain of the CA
    • Keystore has the cert and key ( client side )

    On the server side,

    •  - update the channel def with SSLAUTH=required
    • cipher
    • on the chl auth adjust the rule to allow for a specific CNNAME of the client; You can also add serial number etc.. 

    Note if the client cert is signed with different CA, Qmgr keystore would need the CA root cert.

    Also ensure the queue manager is CRL/OSCP defined, just in case a cert is revoked the queue manager can block the client connection



    ------------------------------
    om prakash
    ------------------------------