If you make changes to your queue manager’s configuration or keystore contents then for those changes to be picked up, assuming that some TLS channels have already been started, you must execute the refresh security command. There is a window of time that the configuration of a queue manager and the internal representation of that configuration do not match up… Refresh Security type(SSL) However, there is one issue with this approach. Runmqakm -cert -details -db /run/runmqserver/tls/key.kdb -stashed -label mycertificateĪnd with that we now can see the distinguished name (and other information) of the certificate that our queue manager has been configured to use. The certificate it has been configured to use has the label ‘mycertificate’Īrmed with this information I can use the IBM MQ certificate management tools to look at the certificate in that keystore to see what my queue manager has been configured to use:.Remember, IBM MQ automatically appends ‘.kdb ’ onto the end of the keystore filename.The keystore it has been configured to use is ‘/run/runmqserver/tls/key.kdb’.Here you can see that my queue manager thinks the following: You can get both of those using runmqsc with the DISPLAY QMGR command: CERTLABL = The certificate the queue manager has been configured to use.SSLKEYR = The keystore that the queue manager has been configured to use.Working out what certificate your queue manager configuration believes it is using.įor this example, the first step would be to look at the queue manager configuration, specifically two attributes on the qmgr: The queue manager configurationįirst let’s look at a simple case. These are the channel types: SVRCONN, RCVR, SVR and the cluster variants of them. I’ve also only looked at distributed queue managers for giving examples of configuration/commands but the principles in here will apply to other platforms.įor the sake of brevity as well I’m only going to look at the cases where a queue manager acts as a TLS server as well. The version doesn’t matter too much currently as the last big change to TLS certificates and identity was back in version 8.0 of MQ where we added the multiple certificates feature and ability to declare what certificate to use by label in the queue manger configuration (more on this later). I’ll be only talking about distributed platform queue managers acting as TLS servers and assuming a version of 9.2 (which at the time of writing is the latest). There’s a couple of assumptions that I’m making here to try and simplify this blog post. In this post I’ll take you through some of these with the hopes to help you answer the question in the future for your own deployment of MQ. But it slowly dawned on me that there’s a few gotcha’s, if’s, but’s and maybe’s that make answering this question a little more complicated. At first, I thought that the answer to this question was easy, just examine the queue manager’s configuration and keystore. Recently on a customer call I was asked “ how can I tell what certificate my queue manager is using to identify itself with TLS?”.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |