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.#MQ