Integration


This is an IBM Automation portal for Integration products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas

  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.


Add a new idea Subscribe
Status Under review
Workspace MQ, MQ Advanced & MQ Appliance
Created by Guest
Created on Sep 30, 2025

RELATED IDEAS

CERTLABL for auto-defined cluster sender channels

Certificate Authorities will be enforcing in the near future that the EKU extension of X509 certificates are separated between client side and server side certificates. There is a need in IBM MQ to be able to have both a client and server certificate for the queue manager. This will require the admin to be able to assign sender type channels (e.g. SDR, CLUSSDR) to the queue manager client certificate, and receiver type channels (e.g. RCVR, CLUSRCVR) to the queue manager server certificate. It looks like there is the need for IBM MQ to provide a way to assign a CERTLABL to an auto-defined CLUSSDR channel. I at least don't see a way to do this in the product. I don't believe the QMGR CERTLABL is a feasible place to set the client certificate, as that conceptually should be a server certificate and there are currently use cases (e.g. .NET and Java SVRCONN channels) that default to the QMGR CERTLABL as a server side certificate.

Addition on 11/12/2025:

It would also be helpful if there would be a way to use an openssl s_client command against a queue manager with this client CERTLABL (let's call it CERTLABLC for argument's sake) and have a servername that could be passed in to get back the CERTLABLC cert.

Idea priority High
  • Guest
    Aug 31, 2026

    We operate IBM MQ on z/OS, Linux, and Windows, and all our connections are currently protected using TLS. We also use SSLCAUTH on our receiver channel definitions (RCVR and CLUSRCVR) and rely on mutual TLS authentication (clientAuth). We do not want to reduce the current level of security.

    If, due to regulatory requirements and the Chrome Root Program requirements, certificate usage must be separated between serverAuth and clientAuth, we need to understand which supported options are available for IBM MQ.

    The CERTLABL attribute helps only for receiver/sender channel (RCVR/SDR) connections and therefore does not fully address the requirement across the entire MQ infrastructure.

    To ensure a consistent and secure solution throughout our infrastructure, implementation of the enhancement requested in IBM Idea MESNS-I-910 appears to be essential.

    Disabling clientAuth for our connections, or disabling the validation of non-matching EKU values—for example, by changing the Certificate Validation Policy or using GSK_CERT_VALIDATION_MODE on z/OS—is not an acceptable solution for us. Such measures would likely be assessed as an IT security risk within our organisation.

    IBM MQ is introducing EKU validation; however, public CAs will soon no longer issue certificates containing both clientAuth and serverAuth. We also expect internal CAs to follow this direction over time.

    What supported technical approach does IBM recommend to maintain mutual TLS authentication while using separate server and client certificates consistently across z/OS, Linux, and Windows?

    Reply

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.