Problem Statement
Currently, GSKit is the only supported way of setting up TLS and cryptography in MQ. Because only IBM products rely on GSKit (as far as I know) it poses a higher barrier to entry when starting with Db2. While GSKit supports standards like PKCS#12 keystores it adds a proprietary layer for stash files - resulting in PKCS#12 files being incompatible with e.g., OpenSSL.
GSKit doesn't have a way of creating a truststore without a private key and thus a password/stash file. For creating trust this is pointless because only the root and intermediate certificates are important. No private keys are used. This makes distributing truststores more difficult than it should be.
GSKit doesn't have a mechanism of an "OS truststore" - something were the OS stores all the certificates it (and utilities running on it) can trust. We maintain these truststores with customer root certificates which helps setting up TLS for many applications. For GSKit-required applications this doesn't work and a new truststore must be created and managed.
During a case we also identified a problem where two different versions were loaded inside one process because both MQ and Db2 was used. This caused a low-level memory exception. The result was that GSKit cannot be safely loaded twice in the same process. OpenSSL doesn't pose such restriction.
GSKit isn't supported by tools like Ansible. A lot of custom code is required to produce the necessary files. An Ansible role was created internally that allows management of truststores and keystores.
Current Workaround
Learning GSKit can be done and the fair amount of documentation and examples help in doing so. Because it is the only option for MQ, there is simply no way around it right now. Sometimes I was asked to implement external TLS implementations (e.g., through HAProxy) for incoming and outgoing connections. This, however, adds another layer of complexity.
For the problem of running both MQ and Db2 in the same process, we are making sure that the MQ GSKit supplied libraries are loaded first via LD_PRELOAD. This is flaky and, as per my understanding, prone to fail in case Db2's version of GSKit is higher than the one MQ is shipped with.
Benefit / Goals
Reduce the barrier of entry for people starting out with MQ
OpenSSL exists for a wide variety of distributions. It is also distributed by them. In case of security fixes these can be easily identified and patched (in many cases, automatically). OpenSSL shouldn't be bundled with MQ.
Make setting up TLS and cryptography much easier to setup for MQ, increasing the use of TLS.
Allow the use of an OS truststore for TLS verification.
Enhance the MQ configuration experience because support is included for other products: Instantly use certificates provided through external key vaults (e.g., Azure KeyVault). Support provisioning with Ansible (it offers a module to create the required files).
OpenSSL isn't just used for TLS but also ships a cryptography library which likely can be used to support the AMS part of MQ.
Easier tracing/debugging of problems because the AMQ.SSL.TRC is only binary and can only be formatted/read by IBM.
The goals could also be implemented as features to GSKit. Because OpenSSL exists and is widely accepted and it already ships that functionality, my suggestions is to reuse something that exists and has proven to work.
