May be you can have a look at MQ IPT (MQ Internet Passrhru).
It act as a relay between two MQ "devices", you can have differents cipher on both sides, ...
I used it recently to connect a MQ 7.1 Queue Manager to a 9.2 one, using TLS 1.2.
Original Message:
Sent: Mon June 24, 2024 10:53 AM
From: Diego Mendoza
Subject: Issue with distribution setup between on-premise Linux and AWS on ROSA(REDHATOPENSHIFT) Platform
Hi Avinash,
Red Hat OpenShift Route depends on the Server Name Indication (SNI) behavior, so you need two IBM MQ installations with SNI support on both sides of the connection. It doesn't matter if different versions of IBM MQ are used, as long as both versions support SNI.
In short, TLS does not provide a mechanism for a client to tell a server the name of the server it is contacting. SNI is an extension to TLS that allows a server receiving a client hello containing the "server_name" extension to guide its selection of an appropriate certificate to return to the client.
If in an IBM MQ connection the SNI-related header is not present when the on-premise side tries to connect to the queue manager deployed in ROSA, OpenShift will present its own certificate, causing the connection to fail.
OutboundSNI is not a channel property; it's more like an environment variable. For example:
For interconnecting Queue Managers, the OutboundSNI property in the SSL stanza of the qm.ini file (on the on-premise side) must be set.
For IBM MQ client connections from outside the OpenShift cluster, the OutboundSNI property in the SSL stanza of the IBM MQ client configuration file must be set.
For a Java application using MQ Classes connecting from outside OpenShift, the com.ibm.mq.cfg.SSL.outboundSNI environment variable must be set.
------------------------------
Diego Mendoza
Cloud Solutions Architect
MicroGestion Software
Argentina
DIEGO_MENDOZA@MICROGESTION.COM
Original Message:
Sent: Mon June 24, 2024 08:41 AM
From: Avinash Kaja
Subject: Issue with distribution setup between on-premise Linux and AWS on ROSA(REDHATOPENSHIFT) Platform
Thanks Diego/Hughson for your response.
So, basically what you are saying is the version difference between On-Premise and AWS ROSA qmgr is what is stopping the SSL connection to come out as successful and Without this upgradation, we won't be able to successfully establish a connection, right?
Also,a quick doubt about the OutboundSNI property,this is generally a property for client channel itself,right?Is that something we can use for a server-server communication?
------------------------------
Avinash Kaja
Original Message:
Sent: Fri June 21, 2024 08:12 PM
From: Morag Hughson
Subject: Issue with distribution setup between on-premise Linux and AWS on ROSA(REDHATOPENSHIFT) Platform
Actually - no strike that, even AllowOutboundSNI is not available until 9.1!
V8 is really rather old - is there an opportunity for you to upgrade to something a little bit more up-to-date? You just don't seem to have the features you need in that well out of date release.
Cheers,
Morag
------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com
Original Message:
Sent: Fri June 21, 2024 02:32 AM
From: Avinash Kaja
Subject: Issue with distribution setup between on-premise Linux and AWS on ROSA(REDHATOPENSHIFT) Platform
Hello All,
Recently, we tried to create a distribution setup between our old on-premise Linux server and a newly created AWS qmgr on Redhat OpenShift platform(Both internal). We basically created the setup and configured the channels(sender and receiver) with SSLV1.2(SHA256) and trying to establish communication.But,we are not able to do so.
So,whenever i try to ping the channel and establish communication ,i am getting "AMQ9665: SSL connection closed by remote end of channel ''. (We have checked all the things like firewall between servers,all the loadbalancer working properly etc).Everything seems fine.But,we are not able to make a successful connection even after adding the SSL certificates we received from CA(internal to the company),exchanged the public to other side qmgr and "Refreshed the SSL Security".
But using the same certs,we are able to connect to the AWS qmgr and PUT/GET messages from local machine as a client communication.But,not able to do server-server communication.
Note : Here our AWS is configured in such a way that any external connection to AWS MQ should have to go through the load balancer(with SSL configuration) which then redirects to 3 available IP-Addresses at MQ level.At Load balancer level,any incoming connection with SSL can only pass through and others(TCP etc) will be rejected.
We tried several things from our end,like updating the same SSLCIPH value(TLSV1.2 or V1.3) at both ends of channels,SSLPEER(CN=* or CN=linux side CN name etc),updating the same CERTLABL at both ends of the qmgr and such things.But always we get the same "SSL connection closed by remote end of the channel" and the channel goes into retrying state and the error logs state as below.
-------------------------------------------------------------------------------
06/20/2024 06:16:28 PM - Process(2496.1) User(mqm) Program(runmqchl)
Host(lxapp4563) Installation(Installation1)
VRMF(8.0.0.7) QMgr(TEST)
AMQ9665: SSL connection closed by remote end of channel 'MQHPSA20.TO.EXAMPQM'.
EXPLANATION:
The SSL or TLS connection was closed by the remote host '10.231.24.161(443)'
during the secure socket handshake. The channel is 'MQHPSA20.TO.EXAMPQM'; in
some cases its name cannot be determined and so is shown as '????'. The channel
did not start.
ACTION:
Check the remote end of the channel for SSL and TLS errors. Fix them and
restart the channel.
----- amqccisa.c : 7839 -------------------------------------------------------
06/20/2024 06:16:28 PM - Process(2496.1) User(mqm) Program(runmqchl)
Host(lxapp4563) Installation(Installation1)
VRMF(8.0.0.7) QMgr(TEST)
AMQ9999: Channel 'MQHPSA20.TO.EXAMPQM' to host
'x.apps.np01.moss.corp.com(443)' ended abnormally.
EXPLANATION:
The channel program running under process ID 2496 for channel
'MQHPSA20.TO.EXAMPQM' ended abnormally. The host name is
'x.apps.np01.moss.corp.com(443)'; in some cases the host name cannot be
determined and so is shown as '????'.
ACTION:
Look at previous error messages for the channel program in the error logs to
determine the cause of the failure. Note that this message can be excluded
completely or suppressed by tuning the "ExcludeMessage" or "SuppressMessage"
attributes under the "QMErrorLog" stanza in qm.ini. Further information can be
found in the System Administration Guide.
So,can anyone suggest what can be done for this to get Resolved and make channels come into running state.
Note : Also,we tried to update some properties such "OUTBOUNDSNI" value at Linux side 'qm.ini' and check once qmgr is restarted.Then we re able to make a successful 'PING' to remote end(AWS),but was not able to start the channel.
Below are the errors at that time.
So,any idea what can be done to resolve this issue?
------------------------------
Avinash Kaja
------------------------------