This post will be the first in a multi-part series talking about configuring various key stores and trust stores IBM MQ and IBM Integration Bus and populating them with certificates.
General Information
Key stores and trust stores are files in a proprietary format. Key stores hold certificates that an application sends across during the SSL handshake. It is the application’s “passport”, if you will. It’s called a “key store” because sometimes certificates are called keys. The terms are very close but not the interchangeable.
When your application sends a certificate to identify itself to the receiving application, it is called one-way authentication or client-only authentication (because your application is the client in this example). When the receiving application sends its certificate back, it’s called two-way authentication or mutual authentication.
When an application receives a certificate, how does it know it should trust it? It can be a self-signed certificate, meaning it was signed by the application that sent it, and it’s basically asking you to trust the computer that sent it. Another kind is a certificate issued by a certificate authority (CA for short) – a company that issues certificates and stakes their reputation and financial well-being behind them. There are several CAs out there, and, if you want to use their certificates, you need to purchase their services through a contract and submit requests for certificates through their interface. CAs offer other services too. E.g. OCSP (Online Certificate Status Protocol) is a service that you can send every certificate issued by this CA to, and they will reply whether or not that certificate has been revoked. Revocation is an action taken by a CA when a computer system becomes compromised, and, it is believed, their certificates (and private keys inside them) might’ve been released into the open.
After you submit your request for a certificate to a CA, they will send you a certificate followed by a series of certificates linked together (you will usually get your certificates by email and there will usually be three other certificates with an option to download them separately). The very last one is the CA root certificate (because all other certificates start from it). The certificates linked to the root certificate are called a chain. Because you use the chain to trust the first certificate, its full name is a trust chain. The trust chain is associated with the CA only, and the very first certificate is associated with the system that requested a certificate. For this reason, it’s called a personal certificate.
Answering our own question, it is the trust chain that the receiving application uses to validate or “trust” the personal certificate. It compares the trust chain sent by the other application to what it has stored. You can download and store all the trust chains from the CAs your company works with and use them for validation. The certificate store that stores the trust chains is called a trust store. The certificate store that stores personal certificates is called a key store.
Tools of the trade
Configured key stores and trust stores are files that can be moved between platforms. For example, you can use graphical tools on Windows to configure a key store for a Linux host and then move the file to the Linux box. Some type of stores (.kdb, .jks) generate more than one file, so, if you move them, make sure to move all of their pertaining files.
We will use IBM Key Management (ikeyman for short) which is a free utility that comes with many of their products (MQ, WAS, etc). It’s a great tool that can be found at c:\program files\ibm\mq\bin\strmqikm or /opt/mqm/bin/strmqikm, if you installed MQ into the default location.
We will be protecting our key store with a good password. You can use another tool provided by IBM to generate a FIPS-compliant password. It can be found at c:\program files\ibm\mq\bin\runmqakm or /opt/mqm/bin/runmqakm, if you installed MQ into the default location. The command to run is:
runmqakm –random –create –length 14 –strong –fips
Look at the screenshots for the examples of the passwords generated by this tool.
I will also provide examples using yet another fee utility runmqckm that comes with MQ.
Different formats exist for key and trust store files, and different tools that work with just those formats or are somewhat universal. Vendor support for various formats and extensions varies. It’s common that you will need to convert a key store from one format to another to make it work with another product on the same host.
CMS – Certificate Management Services, a format used by IBM MQ. Files have an extension .kdb. Pretty useless outside of MQ. Can be accessed with ikeyman, runmqakm, runmqckm, openssl.
JKS – Java Key Store, a format universal in the Oracle/Java world. Usually, a Java application will support only JKS formatted key/trust stores. An example of this is MQ Explore which is based on Eclipse which is a Java application which supports JKS only. Files have extensions .jks. Can be accessed with ikeyman, runmqckm, openssl, keytool.
PKCS#12 – a standard introduced which aims to be one ring to rule them all. Support varies from vendor to vendor. Sometimes supported by Java apps. Files that hold PKCS#12 certificates have an extension .p12. Can be accessed with ikeyman, runmqakm, runmqckm, openssl.
Now we got terminology out of the way and are ready to start working on our stores.
Technical Steps
These steps have been tested on MQ v8 and v9
Launch the ikeyman tool and select the option “create a new key database file”.
Next, select the type of the key store you will be creating. It will depend on what you need it for. The good thing is that you can request a certificate for only one of them and then copy that certificate to other key stores.
- Classic MQ supports CMS type only. We select CMS for “key database type”, file name by tradition is “key.kdb”.
- IIB secure web interface and its many other connections need type JKS, so pick JKS for “key database type”. File name can be “key.jks”.
- IIB secure database connections (in odbc.ini) require type PKCS#12, so choose PKCS12 for “key database type”. File name can be “key.p12”.
Pick a location to store the file where you can easily find it.
Populate the password field with the password you created with the runmqakm command above. If you check the “stash password to a file” box, a stash file will be created, and you will be able to access the file on the file system level without typing in the password.
You can run a command to create a key store too:
runmqckm -keydb -create -db /var/mqm/qmgrs/QM1/ssl/key.kdb -pw password -type cms –stash
The last option used (–stash) stores the password in a file at the same location as the created key store. If you would like to access your key store later, e.g. to list the certificates inside, you can type the option –stashed instead of the password and the command will take the password from this file. Example:
runmqakm -cert -list -db /var/mqm/qmgrs/QM1/ssl/key.kdb –stashed
Another point to make here is to put the key store on the shared disk location if you’re setting up TLS for multi-instance queue managers.
Creating trust stores is similar.
- MQ doesn’t use a trust store.
- IIB needs a JKS trust store and a PKCS12 trust store. Choose “create a new key database file” from the menu above, choose the appropriate type from the drop-down and enter a name. The names could be “trust.jks” and “trust.p12”. You should store them with the corresponding key stores.
Stay tuned
In the next post, we will talk about creating a certificate request, submitting it to the Certificate Authority, receiving a certificate and installing it into your key stores and trust stores.
Need to know is there any way by which we can recover certificate request or add certificate request (CSR) again to the key database, if it is not present in the keystore..Since tried a lot but could not find the way to add the CSR which is not present in the key store…Signed certificate has also generated from CA, but import of the same is failed since CSR request file is not present in the keystore..