![]() If our channel name was, this channel name would translate to the TLS extension servername of .ibm.com. There is also a Unix script at the bottom of this blog that is an aid to do this channel name to servername translation. However, the channel name needs a special format described in the following IBM support document. So how do you use openssl s_client when interacting with an IBM MQ queue manager that is v8 or higher and could be using a CERTLABL configuration that allows there to be multiple personal certificates in use for this queue manager? This is done by using the -servername option of openssl s_client and providing the channel name that we are using to interact with this queue manager in the -servername option. Using openssl s_client with IBM MQ and CERTLABL This CERTLABL change made things more complex when using openssl s_client with IBM MQ. However, at IBM MQ v8 the CERTLABL functionality was added which allows there to be more than one personal certificate in the queue manager keystore that can be referenced by an IBM MQ queue manager. a certificate with the label ibmwebspheremqqm1 on Linux). ![]() This is because prior to IBM MQ v8, a queue manager named QM1 would only reference one personal certificate in its keystore (e.g. The above usage of openssl s_client is straight forward and was easy to use prior to IBM MQ v8. This data can be helpful in debugging certain types of TLS issues. You could then place the PEM format of this certificate in a file called cert.pem and use an openssl command like the following to read the contents.Īnother helpful piece of data in the openssl s_client output is a list of all the signer certs that this remote queue manager is trusting. The PEM format starts with “BEGIN CERTIFICATE” and ends with “END CERTIFICATE”. The output would normally be a lot of data, that would include near the top of the output the personal certificate that the queue manager is using in a PEM format. The openssl s_client command can be a helpful tool when working with IBM MQ TLS.įor example, if you wanted to get the personal certificate of a remote queue manager that is on server1 and listening on port 1414 (maybe because you want to check its expiry date), you can run the following command: When the encrypted CLNTCONN channel connects to the encrypted SRVCONN channel, a TLS handshake is performed and a TLS connection is established. From an IBM MQ channel standpoint, an encrypted CLNTCONN channel would act as a TLS client and an encrypted SVRCONN channel would act as a TLS server. The s_client option of the openssl command allows you to act as a TLS client and perform a TLS handshake with a TLS server. You can use Openssl by running the command openssl. There are also Openssl downloads for Windows that are easy to download and set up that you can find on the internet. The Linux distributions I work with come with it already installed. Openssl is an open source toolkit for Transport Layer Security (TLS) and Secure Socket Layer (SSL). If not, it might be helpful to first review these sections in the MQ manual to gain some more context. This blog assumes you have a general understanding of working with IBM MQ TLS and also the IBM MQ CERTLABL functionality. This blog post covers some of the ways that you can use the tool openssl s_client for some of your IBM MQ TLS (Transport Layer Security) needs. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |