Note the information below is documented the same in MQ v8.0.0, v9.0.0, and v9.1.0 knowledge centers.
IBM Documents that in the
IBM MQ 8.0.0 Knowledge center page IBM MQ>Security>Security overview>IBM MQ security mechanisms>Security protocols in IBM MQ>The SSL or TLS key repository>Digital certificate labels, understanding the requirements the following:
IBM MQ Version 8.0 supports the use of multiple certificates on the
same queue manager, using a per-channel certificate label attribute.
Inbound channels to the queue manager (for example, server connection
or receiver) rely on detecting the channel name using TLS Server Name
Indication (SNI), in order to present the correct certificate from the
queue manager.
The same page also documents this:
Note that inbound channels (including receiver, cluster-receiver,
unqualified server, and server-connection channels) only send the
configured certificate if the IBM MQ version of the remote peer fully
supports certificate label configuration, and the channel is using a
TLS CipherSpec.
In all other cases, the queue manager CERTLABL parameter determines
the certificate sent. In particular, the following only ever receive
the certificate configured by the CERTLABL parameter of the queue
manager, regardless of the channel-specific label setting:
- All current Java and JMS clients.
- Versions of IBM MQ prior to Version 8.0.
IBM also documents the similar information in the IBM MQ 8.0.0 Knowledge center page IBM MQ>Reference>Configuration reference>Channel attributes>Channel attributes in alphabetical order>Certificate label (CERTLABL):
Inbound channels (including RCVR, CLUSRCVR, unqualified SERVER, and
SVRCONN channels) will only send the configured certificate if the
IBM® MQ version of the remote peer fully supports certificate label
configuration and the channel is using a TLS CipherSpec. If that is
not the case, the queue manager CERTLABL attribute determines the
certificate sent. This restriction is because the certificate label
selection mechanism for inbound channels depends upon a TLS protocol
extension that is not supported in all cases. In particular, Java™
clients, JMS clients, and all versions of IBM MQ prior to Version 8.0
do not support the required protocol extension and will only ever
receive the certificate configured by the queue manager CERTLABL
attribute, regardless of the channel-specific label setting.
As you stated Java 8 does support SNI, but apparently IBM has not yet implemented the feature in the IBM MQ Classes for Java or IBM MQ Classes for JMS.
One possible solution I can think of is that you could figure out which underlying function MQ calls to create the TLS session and override this to set the SNI attribute to a value that MQ will recognize on the queue manger with code like the following:
SSLParameters params = sslSocket.getSSLParameters();
params.setServerNames(serverNames);
sslSocket.setSSLParameters(params);
IBM has documented the format that the channel name is passed in the SNI in the Technote "IBM WebSphere MQ: How does MQ provide multiple certificates (CERTLABL) capability":
The SNI address used by MQ is based upon the channel name that is
being requested, followed by a suffix of ".chl.mq.ibm.com".
MQ channel names are mapped to be valid SNI names as follows:
- Upper case letters A-Z are folded to lower case
- Digits 0 through 9 are left unchanged
- All other characters including lower-case letters a-z are converted into their 2-digit hexadecimal ASCII character code followed by a
hyphen.
- lower case letters a through z map to "61-" through "7a-" respectively
- percent (%) maps to "25-"
- hyphen (-) maps to "2d-"
- dot (.) maps to "2e-"
- forward slash (/) maps to "2f-"
- underscore (_) maps to "5f-"
On EBCDIC platforms, the channel name is converted to ASCII before
this mapping is applied. As an example, channel name "TO.QMGR1" maps
to an SNI address of "to2e-qmgr1.chl.mq.ibm.com".
By contrast, the lower case channel name "to.qmgr1" maps onto SNI
address of "74-6f-2e-71-6d-67-72-1.chl.mq.ibm.com".
