The fix for OPEN z/OS APAR OA68554 will introduce more control over GSK_CERT_VALIDATION_MODE for TLS 1.3 https://www.ibm.com/support/pages/apar/OA68554?mhsrc=ibmsearch_a&mhq=OA68554

Hi @Josh McIver - I will see if i can get guideance from the MQ HP-NS team to add to this blog post.

Hi @Colin Sheppard - MQIPT loads the PKIX TrustManager explicitly rather than using the default JRE TrustManager (which can be changed in the java.security properies file) This TrustManager enforces to RFC5280 standards. It is not possible to ask MQIPT to use a different TrustManager algorithm or to use the default TrustManager.

Hi @Tim Zielke - Thank you for sharing the CHAD exit as an option for cluster channels (and thank you for raising the Aha! idea as well)

As a note, if an IBM MQ configuration is struggling to support the EKU enforcement due to CLUSSDR channels, there is the option to use a CHAD exit to set the CERTLABL on the CLUSSDR channel. There is a CHAD exit being provided here that I have validated works on Linux.

https://github.com/ibm-messaging/mq-exits/tree/master/channel/amqsxlbl

Clearly, no one should be sending a certificate with an EKU that only supports server authentication and expecting that to work for client authentication. That is akin to sending an expired certificate and expecting that to be honored. You are in violation of the TLS standards and your only option is to conform to the standards.

@Rob Parker can you clarify your previous response regarding IPT, specifically the statement "MQIPT uses the JRE supplied with it and directly loads a TrustManager which enforces the EKU if present. It is not possible to change this logic.".

Are you saying it is not currently possible to change the logic in the default TrustManager i.e. there is no exposed environment variable or property in the security policy that can stop EKU validation?

Or are you saying it will never be possible to change this logic/behaviour in IPT?

We are already starting to have impact from the EKU changes and, if the counterparty is not willing to work with their chosen TTP CA to provision a certificate with clientAuth usage in the EKU, the other options to mitigate this all significantly weaken our security.

@Rob Parker can you please add details in your table for IBM MQ for HPE NonStop V8.1?

I did submit this need to be able to set the CERTLABL on an auto-defined CLUSSDR channel as an RFE/Idea.

https://ideas.ibm.com/ideas/MESNS-I-910

Just to clarify some points:

1) The new Extended Key Usage restriction rule is not from a standard. Certificate / TLS related implementations follow standard RFCs. The RFCs related to EKU are 5280, 3280 and 2459, with 5280 being the most restrictive.

2) Notice the subtle difference.
Quote from RFC 2459:
This extension may, at the option of the certificate issuer, be either critical or non-critical. If the extension is flagged critical, then the certificate MUST be used only for one of the purposes indicated.

Quote from RFC3280 and RFC5280:
This extension MAY, at the option of the certificate issuer, be either critical or non-critical. If the extension is present, then the certificate MUST only be used for one of the purposes indicated.

3) System SSL allows the setting of the EKU check through the environment variable GSK_CERT_VALIDATION_MODE. Just like any environment variables, if it is not explicitly set, System SSL would use the default value.

Quote from System SSL book environment variable table:
GSK_CERT_VALIDATION_MODE
A value of 2459 specifies certificate validation against RFC 2459 only. A value of 3280 specifies certificate validation against RFC 3280 only. A value of 5280 specifies certificate validation against RFC 5280 only.
A value of ANY specifies certificate validation against RFC 2459 initially
- if that fails, validate against RFC 3280 - if that fails, validate against RFC 5280. The default value is ANY.
If TLS V1.3 is negotiated for a secure connection, certificate validation is done according to RFC 5280 unless explicitly specified.

In other words, ANY is the default for TLS1.0, 1.1, 1.2 and 5280 is the default for TLS1.3. If you don't want to use the default, you need to set the SSL environment variable.

4) MQ calls System SSL functions. It may or may not make use of the System SSL environment variables, specifically GSK_CERT_VALIDATION_MODE. To be confirmed by the MQ team.

5) The issue triggered by this new EKU restriction is about MQ mutual authentication using one single certificate. After the certificate providers implement the policy of not issuing a certificate with both serverAuth and clientAuth extended keyusages, the issued certificate would have only serverAuth keyusage. When MQ uses this certificate as a client certificate, and the EKU checking rule is 5280 or 3280, handshake will fail.

6) Possible solutions:

a. Get a certificate without EKU

b. Get 2 certificates, one with serverAuth, one with clientAuth

c. Keep using the server certificate with serverAuth for the client IF the EKU is non-critical and specifying RFC2459 through the System SSL variable GSK_CERT_VALIDATION_MODE

*option c needs further confirmation

As we work with this industry shift to have CAs enforce separate certificates for client and server certificates, there is going to be a need to have the queue manager for mutual TLS authentication (at least for mainframe) to support both a client and server certificate in the queue manager keystore and assign these certificates to the correct channels (e.g. SDR channel gets a client cert, RCVR channel gets a server cert, etc.). One hole I am potentially seeing is with the auto-defined CLUSSDR channel. I don't see a way right now to tell the queue manager to assign a client cert to an auto-defined CLUSSDR channel. I also would not want an auto-defined CLUSSDR channel to have to rely on the QMGR CERTLABL, as that conceptually should be a server cert, in my opinion.  Plus there are Java and .NET scenarios where these clients only receive the QMGR CERTLABL cert which would require it to be a server cert. Am I understanding correctly this potential hole? If so, I would like to submit an RFE for this functionality to explicitly assign a client cert (i.e. not the QMGR CERTLABL cert) to an auto-defined CLUSSDR channel.

Hi Rob,

I looked at the DigiCert link, and it does say the following:

• Mutual TLS (mTLS), server-to-server authentication, or other authentication use cases
  If your organization requires the Client Authentication EKU in your DigiCert TLS certificates for mTLS or server-to-server authentication, then action is required. DigiCert has excellent options available for our customers and partners who require the client authentication EKU beyond May 1, 2026."

So it does look like they will be providing options for requesting certificates that have an EKU of clientAuth after these changes are implemented.

The Let's Encrypt link was more terse, and it wasn't clear if they would offer that or not.

Hi Tim,

The wording in the blog post and whether Public CAs were removing the ability to request certificates with an EKU stemmed from the change notices given by both DigiCert and Let's Encrypt.

DigiCert states:

On May 1, 2026

DigiCert will fully remove the Client Authentication EKU from our public TLS certificate issuance process for all certificates, including renewals, reissues, and duplicate certificates. The option to choose the Client Authentication EKU during enrollment for public TLS certificates will no longer be available.

How does this affect you?

After May 1, 2026, public TLS certificates issued by DigiCert will no longer be usable for client authentication.

Let's Encrypt states:

May 13, 2026: the tlsclient ACME profile will no longer be available and no further certificates with the Client Authentication EKU will be issued.

Thank you for sharing the SSL.com change notice. I will add it to the post too. Their FAQ Question 6 states:

Q6. Can I still get a publicly trusted certificate with only Client Authentication EKU?  Some CAs, like SSL.com, offer dedicated client authentication certificates. These are separate from TLS certificates and typically used for enterprise authentication. 

The end section "Actions to take" of my blog post recommends looking at your public CA change notice for what your options are if you are using a public CA product that is affected. If that public CA offers an alternative product you can transistion to then that could be considered.

When I read the blog post, I came away with an impression that public CAs were removing the ability to request certificates with an EKU of clientAuth at some point in the near future. That was probably not your intention. I followed up with this from someone on my security team, and he pointed me to a link that said an admin should still be able to request certificates with an EKU of clientAuth from a public CA, they will just have to be separate from the certificates with an EKU of serverAuth. He gave this link as an example for ssl.com (Removal of the Client Authentication EKU from TLS Server Certificates – What You Need to Know - SSL.com). So then you can still do mutual TLS authentication for a mainframe queue manager with a public CA after these EKU changes are implemented. You would just need to request two certificates (one for the EKU clientAuth and one for the EKU serverAuth). Then you would need to use the CERTLABL on the channel definition to tie the RCVR channel to the EKU serverAuth and the SDR channel to the EKU clientAuth certificate. My original question was around a concern that doing something like the above might not be possible for a public CA in the near future.

Hi Josh - MQIPT uses the JRE supplied with it and directly loads a TrustManager which enforces the EKU if present. It is not possible to change this logic. 

I'm not aware of a way to disable this logic. If i find one i will update the blog post.

Hi Tim - Mutual TLS is one of the main ways to perform authentication between two queue managers. Another would be to use something like Channel Authentication or a pair of security exits.

Is it possible to configure MQIPT to not enforce the EKU value?  If so will IBM make this a default in future MQIPT releases?

Same question for z/OS?

As a follow up question to this blog post, am I correct in understanding that for a QM1->QM2 channel connection, the only way for QM2 to authenticate QM1 is through TLS mutual authentication?