Those who are familiar with IBM MQ channel authentication rules (or SSLPEER on a channel definition) are probably aware that you can validate a peer certificate by the serialnumber. For example,
SET CHLAUTH('CLIENT.TLS.SERVER') TYPE(SSLPEERMAP) USERSRC(CHANNEL) +
DESCR('Expires=2022-03-02') +
SSLPEER('SERIALNUMBER=96:00:02:ab:9c:75:99:a5:39:ea:15:3d:14:00:00:00:02:ab:9c,CN=QM1') +
SSLCERTI('CN=CorpIntmCA1')
When you view your certificate to get the serialnumber for your CHLAUTH rule, I ran across a scenario where you will want to be careful what tool you use.
For example, tools like openssl and keytool will see the above serialnumber like this:
96:00:02:ab:9c:75:99:a5:39:ea:15:3d:14:00:00:00:02:ab:9c
And tools like iKeyman and gskit will see the above serialnumber like this:
00:96:00:02:ab:9c:75:99:a5:39:ea:15:3d:14:00:00:00:02:ab:9c
Based on numerous examples, this seems to happen when the lead byte has the high bit set to 1 or in other words is greater than 7 (e.g. 8F, 9C, A1, etc.).
So for this above example, you actually need a CHLAUTH rule like follows for IBM MQ to accept the certificate:
SET CHLAUTH('CLIENT.TLS.SERVER') TYPE(SSLPEERMAP) USERSRC(CHANNEL) +
DESCR('Expires=2022-03-02') +
SSLPEER('SERIALNUMBER=00:96:00:02:ab:9c:75:99:a5:39:ea:15:3d:14:00:00:00:02:ab:9c,CN=QM1') +
SSLCERTI('CN=CorpIntmCA1')
Personally, I add two rules to just cover myself, in case this 00 prepending behavior ever changes with gskit.
SET CHLAUTH('CLIENT.TLS.SERVER') TYPE(SSLPEERMAP) USERSRC(CHANNEL) +
DESCR('Expires=2022-03-02') +
SSLPEER('SERIALNUMBER=96:00:02:ab:9c:75:99:a5:39:ea:15:3d:14:00:00:00:02:ab:9c,CN=QM1') +
SSLCERTI('CN=CorpIntmCA1')
SET CHLAUTH('CLIENT.TLS.SERVER') TYPE(SSLPEERMAP) USERSRC(CHANNEL) +
DESCR('Expires=2022-03-02') +
SSLPEER('SERIALNUMBER=00:96:00:02:ab:9c:75:99:a5:39:ea:15:3d:14:00:00:00:02:ab:9c,CN=QM1') +
SSLCERTI('CN=CorpIntmCA1')
Anyway, it is kind of a quirk, but something to be aware of if you work with IBM MQ channel authentication and serialnumber validations of certificates.