MQ

 View Only

 MQ Client Authentication: Enforcing Certificate-Only Auth and Suppressing OS User ID (.NET / Java)

Martin Kahánek's profile image
Martin Kahánek posted 03/13/26 03:41 PM

Hello,

We are currently facing a challenge integrating with a customer's IBM MQ environment. Our client application runs in an OpenShift container, and the customer has shared the following channel configuration with us:

DEFINE CHANNEL(CLI.OUTPUT.1) CHLTYPE(SVRCONN) MAXMSGL(8388608) 
ALTER CHANNEL(CLI.OUTPUT.1) CHLTYPE(SVRCONN) SSLCAUTH(REQUIRED) SSLCIPH(ANY_TLS12_OR_HIGHER) 
ALTER CHANNEL(CLI.OUTPUT.1) CHLTYPE(SVRCONN) SSLPEER('CN=ABCD, O=xyz a.b.')

The Goal

We need to use only the TLS certificate to authenticate and authorize for consuming messages. This is currently normally used flow as described by the customer, without any need of specifying the UserId or Password in the client library.

The Problem

By design, the XMS.NET library automatically captures the OS User ID running the container (which in OpenShift is an arbitrary/randomized UID) and sends it to the MQ server. This triggers an authorization collision on the server, as it attempts to validate this unknown User ID in addition to the TLS certificate.

We are strictly unable to request changes to the server-side channel setup (e.g., we cannot ask the customer to map the certificate to an MCAUSER or alter their CHLAUTH rules). We must handle this entirely on the client side.

Currently, it behaves as follows:

  • Error Code: 2035 - MQRC_NOT_AUTHORIZED

  • Setup: Container runs as user ABCD and connection factory is setup as follows:
    

    var connectionFactory = xmsConnectionFactoryProvider.CreateConnectionFactory();

    var mqConfig = _serviceConfiguration.MqConfig!;

    connectionFactory.SetStringProperty(XMSC.WMQ_CONNECTION_NAME_LIST, connectionNameList);
    connectionFactory.SetStringProperty(XMSC.WMQ_CHANNEL, qmConfig.Channel);
    connectionFactory.SetStringProperty(XMSC.WMQ_QUEUE_MANAGER, qmConfig.Id);
    connectionFactory.SetIntProperty(XMSC.WMQ_CONNECTION_MODE, XMSC.WMQ_CM_CLIENT);
    connectionFactory.SetIntProperty(XMSC.WMQ_CLIENT_RECONNECT_OPTIONS, XMSC.WMQ_CLIENT_RECONNECT_Q_MGR);

    connectionFactory.SetStringProperty(XMSC.WMQ_SSL_KEY_REPOSITORY, mqConfig.CertificatePath);
    connectionFactory.SetStringProperty(XMSC.WMQ_SSL_KEY_REPOSITORY_PASSWORD, mqConfig.CertificatePassword);
    connectionFactory.SetStringProperty(XMSC.WMQ_SSL_CIPHER_SPEC, "TLS_RSA_WITH_AES_256_CBC_SHA256");

    var connection = connectionFactory.CreateConnection();
    connection.Start();

  • Logs: 

    AMQ9557E: Queue Manager User ID initialization failed for 'abcd'
    EXPLANATION:
    The call to initialize the User ID 'abcd' failed with CompCode 2 and Reason
    2035. If an MOCSP block was used, the User ID in the MOCSP block was ''
    . If a userID flow was used, the User ID in the UID header was '' and any CHLAUTH rules applied prior to user adoption were evaluated case-sensitively against
    this value.

Our Questions

  1. .NET Capabilities: Do we understand correctly that it is currently not possible to suppress the OS User ID with any of the .NET client libraries (including XMS.NET)? If there is a way to configure the connection factory to drop the User ID and rely solely on the certificate, what is it? (We were unable to find a client-side solution for this in the documentation).

  2. Java Capabilities: Is this possible using the MQ Java client? Specifically, can we configure the Java client to not send the local user ID and rely completely on the certificate?

Thank you for your guidance and support.

Rob Parker's profile image
Rob Parker posted 03/16/26 04:10 AM

Hiya,

The behaviour you describe is not limited to XMS .NET clients. All client types of IBM MQ (C, JMS, .NET) provide the queue manager with the userid that the application is running as. The reason for this is that IBM MQ's authority model is a user based authority model. As such, somewhere in the authentication stages of MQ we need to end up with a user we can identify the connection as and authorize against. In IBM MQ the order of preference for obtaining a user to use for identity is: 

  1. User the application is running as. (Not recommended)
  2. User defined in Channel MCAUSER field
  3. User authentication by Connection Authentication (only if CONNAUTH and ADOPTCTX(YES) are used)
  4. User set via a mapped channel authentication record (USRSOURCE(MAP) + MCAUSER)
  5. A security exit

As you are connecting only with TLS certificates and the TLS Certificates cannot be used as an identity for MQ's authority model, the queue manager has to source the identity from somewhere else. In your case it is the first option. 

Your options here, as the application owner, are to run the application as a different user. I'm not aware of a way programmatically to change what user the application runs as. 

Francois Brandelik's profile image
Francois Brandelik IBM Champion posted 03/16/26 08:06 AM

Hi Martin,

You are missing the overrides for XMS/JMS 

var connection = connectionFactory.CreateConnection(user,password);

and remember to set on the connection factory the USE_MQCSP_AUTHENTICATION_PROPERTY to true.

As user, password tuple use a user and password that the MQ server will accept and has authorizations for.

As an alternative you could also use the mqccred client side security exit... (and or a CCDT).

Enjoy

om prakash's profile image
om prakash IBM Champion posted 03/16/26 05:44 PM

Make sure the CN=xxxxx where `xxxx` is authorized by the queue manager. Chlauth rule should exists on the queue manager. Also the certificate should be `Client Certificate`. Not a server certificate.

  • Build a Key Store ( keep the cert + key )
  • Have a truststore ( keep the cert signer and the queue manager public ca cert )

for the error, in Java we would pass as below, so the client does not pass the userid/password.

ibm.mq.user=

Related Content