MQ

Using Serialnumber with TLS Authentication in IBM MQ

This blog post discusses why an MQ administrator may want to consider validating the certificate serialnumber when doing IBM MQ TLS (Transport Layer Security) channel authentication.  This blog assumes you have a general understanding of working with TLS and IBM MQ channels and channel authentication rules.  If not, it might be helpful to first review these topics in the IBM MQ manual.  We also will be assuming we are working with CA (Certificate Authority) signed certificates in our blog post.

TLS Authentication in IBM MQ

One of the ways you can authenticate a channel in IBM MQ is with the X.509 certificate that is passed over a TLS connection.  For example, if you have a Java client making an encrypted CLNTCONN channel connection to an IBM MQ queue manager encrypted SVRCONN channel, the IBM MQ queue manager can validate details of the Java client certificate in order to determine if the channel should be allowed to run.  A certificate has a Subject field that is populated with Distinguished Name (DN) attributes.  For example, the certificate might have a Subject DN of CN=myJavaApp,OU=MQAPP,C=US.  You can define with an IBM MQ CHLAUTH rule or SSLPEER channel attribute for there to be a check that the SVRCONN channel will only run if the remote certificate has a DN of “CN=myJavaApp,OU=MQTEST1,C=US”.

Serialnumber in a Certificate

Along with the Subject DN of a certificate, another field that you can validate in IBM MQ TLS channel authentication is the serialnumber of the certificate.  In section 4.1.2.2 of the RFC5280 specification of X.509 Public Key Infrastructure Certificates, the serialnumber is defined as the following:

As you can see in the specification, it is the serialnumber that uniquely defines a certificate for a given CA.  Note that it is both the serialnumber and issuer name that identify a unique certificate.  We will discuss later how to use this combination of serialnumber and issuer name to better validate a certificate with CHLAUTH rules.

NOTE:  Although a CA is required by specification to use a unique serialnumber per signed certificate, it would still be a good idea to validate with your CA (and test) that they are doing this.

Only validating the Subject DN of a Certificate for IBM MQ TLS Authentication

Let’s look at the use case where we do not validate on the serialnumber of a certificate, and validate instead on just the Subject DN of the certificate for IBM MQ TLS channel authentication.  In section 4.1.2.6 of the RFC5280 specification of X.509 Public Key Infrastructure Certificates, the Subject name has the following specification:

There are some restrictions being placed here on the CA for the Subject Distinguished Name (DN) of the certificate.  The DN must be unique per subject entity.  However, for a given subject entity there can be multiple certificates with the same DN. 

Now if we are just validating on the Subject DN of the remote certificate for IBM MQ TLS channel authentication, we are opening us up to the possibility for an imposter to create their own private/public key, create a certificate request with a Subject DN that closely matches our real certificate’s Subject DN, and then go to our CA and have them sign their certificate.  As long as their certificate can pass our Subject DN check, the imposter can now connect to our channel.

Now some questions probably arise here.  “How easy is it to go to a CA and get them to sign a certificate with a Subject DN that closely matches the real certificate’s Subject DN?  Wouldn’t there be some type of CA checks to prevent this imposter certificate from being signed?”  Your CA probably has safeguards in place to prevent this from happening or at least to some degree.  However, do you know exactly what the CA is doing to enforce these checks?  Can you say the following with confidence? “It is not possible for an imposter to go to my CA and get a certificate signed who’s Subject DN is close enough to the real certificate where it can pass my IBM MQ channel authentication Subject DN check of the real certificate.”

Validating the Serialnumber of a Certificate for IBM MQ TLS Authentication

Now let’s look at the use case where we do the validation of the serialnumber for IBM MQ TLS channel authentication.  We will also assume that our CA is loose on their controls and it is not that difficult for an imposter to get the CA to sign another certificate with a Subject DN that completely matches the real certificate that we want to validate.

The imposter now comes along and tries to connect to our MQ channel.  Even with a certificate that has an identical Subject DN, they are blocked because we also validate on the serialnumber of the certificate.  Remember a CA will enforce that the serialnumber is unique for any certificate signed.  It is not possible for our imposter to go to our CA and ask them to sign their certificate with the same serialnumber that we are validating on for the real certificate that we want to authenticate.  We have also now completely removed this attack vector of an imposter getting a certificate that can pass our IBM MQ TLS channel authentication check when we just validate the Subject DN of the certificate.

Administering Serialnumber Validation in IBM MQ

As we mentioned in an earlier section, it is both the serialnumber and issuer name that identify a unique certificate.  You can validate both pieces with a CHLAUTH SSLPEERMAP rule that includes the serialnumber and SSLCERTI in its validation.  Here is an example.

SET CHLAUTH('JAVA.TLS.SERVER') TYPE(SSLPEERMAP) USERSRC(CHANNEL) +

DESCR('Expires=2021-03-28') +

SSLPEER('SERIALNUMBER=16:00:02:ab:a3:c0:ab,CN=myJavaApp,OU=MQAPP') +

SSLCERTI('CN=MyCA1,DC=myCompany,DC=com')

For the above CHLAUTH example, the JAVA.TLS.SERVER channel can only run if the Java client presents a certificate that has the SERIALNUMBER=16:00:02:ab:a3:c0:ab and is signed with an issuer whose subject DN is “CN=MyCA1,DC=mycompany,DC=com”. 

Note also how the expiry date is added into the description.  Because SERIALNUMBER and SSLCERTI represent a unique certificate, the expiry date for this certificate can also be tracked in the CHLAUTH rule.  By adding the expiry date into the DESCR, this gives the ability to query our CHLAUTH rules and monitor for when rules can be removed, when remote certificates are about to expire, etc.

From a certificate maintenance standpoint, using a CHLAUTH serialnumber validation approach is not that difficult.  With CHLAUTH rules you can have multiple rules per channel.  This allows you to pre-stage your new serialnumber rule while the current serialnumber rule is still active for a given channel.  Once the new serialnumber rule is pre-staged, your partner MQ queue managers and clients can bring in their new certificate at their leisure. 

If a partner does bring in a new certificate and does not notify you, modern queue managers report the serialnumber of the failing certificate in the queue manager error log.  With this information, you can work with your partner to confirm that the certificate has changed and then add in the new rule for this new serialnumber.  

 

Tools for Building a Certificate Expiry Report

The previous section explained how CHLAUTH rules that represent a unique certificate (with serialnumer and issuer in the check) can have the expiry date of the unique certificate also added to the rule (e.g. in the description) for useful purposes.  One of the uses mentioned is the ability to build a certificate expiry report from the CHLAUTH rules.  If you are looking for tools to aid in this process, one tool you could use is the mqsc-qmgrs script documented in this blog post:

https://community.ibm.com/community/user/imwuc/blogs/tim-zielke1/2020/07/09/mqsc-qmgrs-script

With the mqsc-qmgrs script, you can query all the CHLAUTH rules for your MQ estate and get them into a file where each CHLAUTH rule is on one line so you can more easily parse the data.  For parsing the data to build the certificate expiry report, I wrote a Java program to do this.  A Unix script could be another option.  I found this approach very helpful as our MQ team now has a daily report of when all the MQ certificates (both on the queue manager and client side) in our estate are expiring.

Here are some more specific examples of how I have built this certificate expiry report.

Below is the Linux script that I use to call the mqsc-qmgrs script to get the CHLAUTH rules for all my queue managers and then pass this data to a Java application called mqcertexpiry.jar that produces the report. The mqcertexpiry.jar can be found in the Latest Files section of the MQ Community home page. The Java source code for mqcertexpiry is also included in the jar file.

#!/bin/bash
cd /home/mqm/tools
echo "NOTE: This report is generated from CHLAUTH rules where Expires= (case sensitive) is in the DESCR" > mqcertexpiry.out
echo >> mqcertexpiry.out
export MQCHLLIB=/home/mqm/tools
export MQCHLTAB=ccdt.json
export MQSSLKEYR=/home/tools/ssl/key
./mqsc-qmgrs ALL certexpiry
if [[ $? -eq 0 ]]; then
   cp -p mqsc-qmgrs-certexpiry-output-all-1LS certexpiry.in
   java -jar mqcertexpiry.jar >> mqcertexpiry.out 2>&1
   cat mqcertexpiry.out | mailx -s "Cert Expiry Report" john.smith@company.com
else
   echo "mqsc-qmgr invocation failed!" | mailx -s "Cert Expiry Report" john.smith@company.com
fi


Here is an example of what the Cert Expiry report looks like:

NOTE: This report is generated from CHLAUTH rules where Expires= (case sensitive) is in the DESCR

expiryDate=2021-06-02

sslpeer=SERIALNUMBER=16:00:02:d5:ed:c9:8f:49:9a:3c:b9:af:ff:00:00:00:02:d5:ed,CN=app1.company.com,OU=MQ.TEST.CLIENT

sslcerti=CN=CorpSubCA1,DC=company,DC=com

chlauth=APP1.TLS.SERVER

qmgrs=QM1,QM2,QM3

expiryDate=2021-06-22

sslpeer=SERIALNUMBER=16:00:02:d5:ed:c9:8f:49:9a:3c:b9:af:ff:00:00:00:03:e4:ad,CN=app2.company.com,OU=MQ.TEST.CLIENT

sslcerti=CN=CorpSubCA1,DC=company,DC=com

chlauth=APP2.TLS.SERVER

qmgrs=QM3,QM4,QM5

From this report, I am now able to track the expiration for all the TLS certificates (both client and queue manager) that are in my MQ environment.

Also, another thing to consider when you have this approach of CHLAUTH rules by certificate serialnumber/issuer, is defining MQ client channels with the certificate expiration date in the name. For example, if the CHLAUTH rule for an MQ client channel of APP1 is defined for a certificate that expires on 05/01/2022, you could define the client channel as APP1.05012022.  The advantage of doing this is that you could then track channel usage (e.g. with MQ accounting) to see if clients have changed over to use a new channel/certificate. Since the MQ clients are required to update their keystores with new certificates with mutual TLS authentication, also adding a channel name change is just one more thing for them to do. 

Conclusion

The serialnumber on a CA signed certificate is what uniquely identifies a certificate for a given CA.  If you are using TLS certificate authentication for how you authenticate your IBM MQ channels, you will want to consider validating both the serialnumer and issuer of the certificate through CHLAUTH rules to make sure you are uniquely validating the certificate of a remote entity.  When it comes to TLS certificate authentication, it is safest to be as specific as possible with your TLS certificate validation.