IBM MQ TLS Client Keystores Do Not Require Intermediate Certificate Authorities

By Tim Zielke posted Fri February 12, 2021 11:37 AM


IBM MQ TLS Client Keystores Do Not Require Intermediate Certificate Authorities

This is a short blog post, but something I found helpful, so I thought I would share. I had a previous misconception about what signer certificates an IBM MQ client requires in its keystore for TLS. For example, if an IBM MQ client (e.g. Java client) needed to trust a queue manager certificate that was signed by an intermediate certificate authority (CA) and the intermediate CA was signed by a root CA, I thought the IBM MQ client end needed both the intermediate CA and root CA signer certificates in its keystore to trust the queue manager certificate. However, this is not the case. Only the root CA is required on the client end to trust the queue manager certificate. Here is a more specific example to help explain.


In this example, we will have a Java client using a TLS CLNTCONN channel to connect to a TLS SVRCONN channel on an IBM MQ queue manager. In this type of MQ channel connection, the Java client acts as the TLS client and the IBM MQ queue manager acts as the TLS server for the underlying TLS connection. The IBM MQ queue manager, which we will call QM1, will have a QM1 personal certificate that is signed by an intermediate CA called CompanySubCA1. The CompanySubCA1 signer certificate will be signed by a root CA called CompanyRootCA. For this example, I was previously under the impression that the Java client side would need both the CompanySubCA1 and CompanyRootCA in its keystore, in order to trust the QM1 queue manager certificate that is sent from the queue manager. However, that is not the case. The Java client only needs the CompanyRootCA in its keystore, and the queue manager keystore should have both the CompanySubCA1 and CompanyRootCA signer certificates in its keystore. When the TLS handshake happens between the TLS client and server, the TLS server side will send the CompanySubCA1 signer certificate to the Java client end. The Java client can then use the sent CompanySubCA1 signer certificate and the CompanyRootCA signer certificate (found in its Java keystore) to authenticate the queue manager certificate.


This approach of only putting the root CA on the client side also helps to reduce TLS administration. For example, as intermediate CA certificates expire and need to be updated, you only need to update the TLS server side (i.e. queue manager side) keystore, to have the new intermediate CA certificates take effect. This obviously saves resource time as you only need to target your TLS servers (i.e. queue managers) and can ignore TLS clients (e.g. Java clients) for intermediate CA changes. If you are familiar with web server certificate management, this probably sounds like common knowledge to you. Maybe it is common knowledge to other MQ admins, as well. However, it was not common knowledge to me, so hopefully someone else finds this information helpful like I did.




Tue February 16, 2021 08:34 AM

Interesting. I am wondering what is the purpose of this attribute. It is not recommended to use anything other than the default setting. Also, I am not following what would be the value of forcing one side to have the entire chain in its truststore, since you can just have the root and the root can be used to validate any intermediate signer certs that are sent from the remote end.

The string can be one of two values:
  • Usepeerchain [Default]: The certificate chain provided by the peer can be used to bridge any trust chain gaps while validating certificates. With the exception of the root certificate.
  • Truststoreonly [Not recommended]: Only certificates in the trust store will be used for validating the peer's certificate.

Tue February 16, 2021 04:45 AM

This is true also on multiplatform queue managers unless PeerCertChainValidation=Truststoreonly (not the default) is set in the SSL stanza of the qm.ini.  The Knowledge center does not reflect a version, but this attribute was added in 9.2.