View Only

Messaging applications on Apple silicon

By Soheel Chughtai posted Tue March 28, 2023 12:07 PM


In 2020, Apple transited from Intel x86-64 to Arm64 (Apple silicon) processors. By basing on their own chips, Apple can make Macs more powerful yet energy efficient. If you replaced your MacOS machine recently, the odds are that it has an Apple silicon processor.  For applications this is problematic as x86 applications don't run on ARM processors and visa-versa. 

Apple expect developers to migrate their native apps to support new devices based on the new processors. For the interim, Apple have provided Rosetta2, allowing apps built for Intel to run via translation on Apple Silicon machines. Xcode has universal binary options and cross-compilation options that allow developers to build universal binaries on either their old X86 machines or new Arm64 machines. 

In theory it seems simple. In practice, it's a little more difficult. 

If you are coding with an interpreted language like Python or Node.js then you are relying on the interpreter to support Apple Silicon. If they aren't then you are reliant on Rosetta2. Your application may have dependencies on libraries that bind to C / C++ code. The entire application stack needs to be homogeneous. IE. The interpreter decides whether the stack needs to be all x86 or all Arm64. If they aren’t then even Rosetta can’t help you.

Why is this relevant to the IBM MQ Advanced for Developers client toolkit?

The toolkit for MacOS lets you develop messaging applications that run on MacOS. The toolkit makes use of native MQ client libraries delivered as universal binaries to support both x86 and Arm64. Whilst the toolkit itself consists of universal binaries it has a downstream dependency for encryption. For x86 the toolkit uses GSKit, for Arm64 it uses OpenSSL.

When you install the toolkit, the installer summary page explains that on a Arm64 machine, the toolkit requires a .pem formatted truststore for TLS.  Further information is in /opt/mqm/README.client

If all you have are key.crt and key.key files, then it's easy to create a .pem. Client authentication only requires the public certificate of the signing authority. Take a look at the key.crt file. If it starts with 


Then it’s already in a .pem format.  Just rename the key.crt file to say qmgrcert.pem, and that is it.

Mutual auth needs more certificates, but you can concatenate them together so the .pem takes a structure akin to 

(SSL certificate) 

(Intermediate certificate) 

(Root certificate: TrustedRoot) 

The relevant section in  /opt/mqm/README.Client begins with the heading


It describes how to extract a queue manager’s certificate and public key. It continues to describe which environment variables to set when using the toolkit samples   in /opt/mqm/samp/bin.


- Set the MQSSLKEYR environment variable to the location of your trust.pem file

  e.g., export MQSSLKEYR=<path_to_your_pem_file>/trust.pem

or if you named it qmgrcert.pem set

export MQSSLKEYR=<path_to_your_pem_file>/qmgrcert.pem

You don't need to do that for the samples in For those simply set KEY_REPOSITORY to point at the .pem file, 

as described in