White Papers
Abstract
This White Paper gives guidance on what makes a certificate authority (CA) chain, what it is used for and how to use tools included with IBM MQ to determine whether you have a fully validated certificate chain. This white paper assumes you understand the basics of certificates.
Content
This article upon the online manual for IBM MQ:
https://www.ibm.com/docs/en/ibm-mq/9.3?topic=concepts-digital-certificates
IBM MQ / 9.3
Digital certificates
https://www.ibm.com/docs/en/ibm-mq/9.3?topic=concepts-digital-certificates
IBM MQ / 9.3
Digital certificates
What Is a Certificate Chain
A certificate chain is used by a certificate authority to "sign" a user's personal certificate. If a certificate is signed by one of these entities, then it can be confirmed it was not a faked certificate and in fact was issued by that entity. Certificate authorities are trusted entities, either a public or private entity. If a certificate was faked, it would not be validated with the public keys of certificates further up the certificate chain. These certificates higher up the chain are often called signer certificates because they are used to ensure lower certificates were signed by the higher certificates. If the certificate chain is not verifiable, then it is assumed that the personal certificate is invalid and the connection is rejected.
What Certificates Are in a Certificate Chain
A certificate chain is made up of three types of certificates: the root certificate, intermediate certificates, and the personal certificate. This section refers to:
https://www.ibm.com/docs/en/ibm-mq/9.3?topic=certificates-how-certificate-chains-work
IBM MQ / 9.3
How certificate chains work
IBM MQ / 9.3
How certificate chains work
The pictured chain is described and examples from the command line and the IBM Key Management tool are displayed in the following paragraphs.
| Root Certificate | Intermediate Certificate | Intermediate Certificate | Personal Certificate | |
| Certificate Subject | CN= Example Root CA, OU=www.example.com, O=Example Organization, C=US |
CN= Example SHA2 CA Intermediate, OU=www.example.com, O=Example Organization, C=US |
CN= Example SHA2 CA US Intermediate, OU=www.example.com, O=Example Organization, L=NYC, C=US |
CN= Example Server 1234 Certificate, OU=www.example.com, O=Example Organization, C=US |
| Certificate Issuer | CN= Example Root CA, OU=www.example.com, O=Example Organization, C=US |
CN= Example Root CA, OU=www.example.com, O=Example Organization, C=US |
CN= Example SHA2 CA Intermediate, OU=ww.example.com, O=Example Organization, C=US |
CN= Example SHA2 CA US Intermediate, OU= www.example.com, O=Example Organization, L=NYC, C=US |
Root Certificate
The root certificate is issued by a top-level certificate authority. Certificate authorities can have one or many root certificates but only one can be used in a certificate chain at a time. The root certificate is the start of the certificate chain. You can identify a root certificate because it has the same subject and issuer. This certificate is a self-signed certificate, the difference between a root certificate and any other self-signed certificate is the level of trust implied by a root certificate. These root certificates are often valid for a long time due to the number of certificates they sign and the high level of trust associated with them. Here is an example of what a certificate authority root certificate's subject and issuer would look like in multiple different formats:
Subject: CN= Example Root CA, OU=www.example.com, O=Example Organization, C=USIssuer: CN= Example Root CA, OU=www.example.com, O=Example Organization, C=US
Intermediate Certificates
The next certificates in the chain are intermediate certificates. There is always at least one intermediate but there can be more than one. These certificates are signed by the root CA, or the intermediate certificate immediately before them in the certificate chain. These often have shorter valid times. There is an example:
Subject: CN= Example SHA2 CA Intermediate, OU=www.example.com, O=Example Organization, C=USIssuer: CN= Example Root CA, OU=www.example.com, O=Example Organization, C=US
Notice that the issuer is the root certificate authority and the subject is our intermediate. The next intermediate certificate in our chain would be signed by this certificate. They are often more specific at lower levels. This specific example has the second intermediate located in NYC. The certificate would look like this:
Subject: CN= Example SHA2 CA US Intermediate, OU=www.example.com, O=Example Organization, L=NYC, C=USIssuer: CN= Example SHA2 CA Intermediate, OU=ww.example.com, O=Example Organization, C=US
Personal Certificates
The final certificate in the chain is the user's personal certificate. It is signed by the last intermediate certificate in the chain. A personal certificate is shown below:
Subject: CN= Example Server 1234 Certificate, OU=www.example.com, O=Example Organization, C=USIssuer: CN= Example SHA2 CA US Intermediate, OU= www.example.com, O=Example Organization, L=NYC,C=US
Certificate Chain
If we follow the certificates, we notice that there is a complete link of issuers and subjects from the personal certificate back to the root certificate.
CN= Example Server 1234 Certificate, OU, www.example.com, O=Example Organization, C=US ⇒ CN= Example SHA2 CA US Intermediate, OU= www.example.com, O=Example Organization, L=NYC, C=US ⇒CN= Example SHA2 CA Intermediate, OU=www.example.com, O=Example Organization, C=US ⇒CN= Example Root CA, OU=www.example.com, O=Example Organization, C=USThis screenshot is an image of the chain in the command line from the server's key repository:
If this chain is incomplete at any step, then the validation of certificates fails.
Testing Certificate Chains
IBM MQ Key Management Tool
The IBM MQ Key Management Tool GUI can validate certificate chains. Notice the following image, it has the Server personal Certificate highlighted in yellow so this certificate is invalid.
There is also the validate button in the key management tool that can perform a validation check.
runmqakm/runmqckm ToolThe
runmqakm/runmqckm utility can validate a certificate. In the following example, the root certificate is missing. The utility alerts us to any invalid certificates. In this case, the Intermediate 1 certificate is invalid because it is missing the root certificate to sign it. The command run was: runmqakm -cert -validate -db personal.kdb -stashed
For more information on the
runmqakm command see:https://www.ibm.com/docs/en/ibm-mq/9.3?topic=windows-using-runmqckm-runmqakm-strmqikm-manage-digital-certificates
IBM MQ / 9.3
Using runmqckm, runmqakm, and strmqikm to manage digital certificates
IBM MQ / 9.3
Using runmqckm, runmqakm, and strmqikm to manage digital certificates
mqcertck ToolThe two tools mentioned previously validate only your certificate chain. They do not look up any OCSP, Certificate Revocation List, or SSLPEER validation settings.
mqcertck will look up this information as well and validate the SSL settings of the whole queue manager. It provides less information about what certificates failed than the previous runmqakm tool but it also validates the TLS settings on the whole queue manager. For more information see:
https://www.ibm.com/docs/en/ibm-mq/9.3?topic=reference-mqcertck-certify-tls-setup
IBM MQ / 9.3
mqcertck (certify TLS setup)
IBM MQ / 9.3
mqcertck (certify TLS setup)
The following command is an example on a queue manager set-up as our example server with the keystore in the default location missing one of our intermediate certificates. The command run was:
mqcertck ExampleServer1234
Conclusion
When creating and configuring keystores for IBM MQ, it is important to have the whole certificate chain on both sides of the connection. Without these keystores, certificates cannot be validated and the connection fails. Check to ensure a proper chain either manually by visually inspecting the certificate chain or using one of the provided tools.
++ Additional Information:
tags: "MQ SSL"; "MQ TLS"; MQSSL; MQTLS
tags: "MQ SSL"; "MQ TLS"; MQSSL; MQTLS
+++ end +++
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"ARM Category":[{"code":"a8m0z00000008JwAAI","label":"Security-\u003ETLS (SSL)"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Version(s)","Line of Business":{"code":"LOB45","label":"Automation"}}]
Was this topic helpful?
Document Information
Modified date:
30 October 2023
UID
ibm16217603