| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| AMQ9206E when running amqssslc |
« View previous topic :: View next topic » |
| Author |
Message
|
| troc |
 Posted: Mon Sep 18, 2023 11:34 pm Post subject: AMQ9206E when running amqssslc |
 |
|
Newbie
Joined: 18 Sep 2023
Posts: 5
|
Dear all,
I am trying to connect to a queue manager via amqssslc, but I get an AMQ9206E error (all the time).
The setup is as follows:
Client (amqssslc) -> BigIP/F5 -> Queue Manager (on F5 the SSL offload takes place).
CA root certificate is imported in the keystore.
With the following command amqssslc is called:
| Quote: |
| /opt/mqm/samp/bin/amqssslc -m TEST -x "host(1415)" -s TLS_RSA_WITH_AES_256_CBC_SHA256 -k "/tmp/ssl/clientkey_4" -c TEST.SVRCONN |
After a few minutes I get the following console output:
| Quote: |
Sample AMQSSSLC start
Connecting to queue manager TEST
Using the server connection channel TEST.SVRCONN
on connection name mq.test.net(1415).
Using SSL CipherSpec TLS_RSA_WITH_AES_256_CBC_SHA256
Using SSL key repository stem /tmp/ssl/clientkey_4
Certificate Validation Policy: 0
No OCSP configuration specified.
MQCONNX ended with reason code 2538
|
The client error log states:
| Quote: |
09/19/2023 08:17:46 AM - Process(8051.1) User(troc) Program(amqssslc)
Host(testhost) Installation(Installation1)
VRMF(9.1.5.0)
Time(2023-09-19T06:17:46.210Z)
RemoteHost(xx.xxx.133.149)
ArithInsert1(104) ArithInsert2(104)
CommentInsert1(ip-xx-xxx-133-149 (xx.xxx.133.149)(1415))
CommentInsert2(TCP/IP)
CommentInsert3((write))
AMQ9206E: Error sending data to host ip-xx-xxx-133-149 (xx.xxx.133.149)(1415).
EXPLANATION:
An error occurred sending data over TCP/IP to ip-xx-xxx-133-149
(xx.xxx.133.149)(1415). This may be due to a communications failure.
ACTION:
The return code from the TCP/IP(write) call was 104 X('68'). Record these
values and tell your systems administrator.
|
When I capture the network traffic, the SSL handshake kind of stops after "Server Hello Done". After that it looks like that amqssslc is resetting the connection. No traffic is going through to the queue manager (so there are not QM logs).
For ruling out any cert validation problems I used a keystore with a non-matching root certificate and got an AMQ9633E error (so it seems that cert validation is not the problem here).
We also have a Java implementation that is working fine (connection to the queue manager can be established with no problems using the same CA root certificate and connection settings). But amqssslc is always failing with these errors.
I'm running out of options ... do you have any idea what the problem could be?
Note: Sensible information has been 'x'ed in the log quotes. |
|
| Back to top |
|
 |
| exerk |
| Posted: Tue Sep 19, 2023 7:42 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
The sample program documentation states:
AMQSSSLC -m [QMGR_NAME] -c [CHANNEL_NAME] -x [CONNAME]
-k [KEY_STORE_PATH_AND_NAME] -s [CIPHER_SPECIFICATION]
-o http://dummy.OCSP.responder
I am assuming you are not using an mqclient.ini file to specify OCSP non-checking, so are you perhaps hitting an OCSP issue on the client end? That said, I would expect that to show up in the client-side logs.
Obvious question, but you have proved connectivity to the server hosting the queue manager, from the client machine?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| troc |
| Posted: Tue Sep 19, 2023 11:19 am Post subject: |
|
|
Newbie
Joined: 18 Sep 2023
Posts: 5
|
Thank you for your reply!
The mqclient.ini looks like this at the moment:
| Quote: |
SSL:
AllowTLSV13=TRUE
ClientExitPath:
ExitsDefaultPath=/var/mqm/exits
ExitsDefaultPath64=/var/mqm/exits64 |
I'll give it a try and will add
| Quote: |
OCSPAuthentication=OPTIONAL
OCSPCheckExtensions=NO |
in the SSL section.
To the 'obvious question': Yes, connectivity has been proved... amqssslc is connecting to the F5 and also some parts of the SSL handshake are done (cipher negotiation, Server Hello Done). Just after the F5 is presenting its certificates, the handshake somehow stops and connection is closed.
As stated in my original post, when using Java/JKS everything is working without problems (from the client machine). |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Sep 19, 2023 2:12 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
Errno 104 is 'connection reset by peer'. Is there anything in the queue manager's error log?
Can you establish a connection to a svrconn channel (eg. using amqscnxc) that does not have SSLCIPH set?
There could be a network / firewall issue.
_________________
Glenn |
|
| Back to top |
|
|
| troc |
| Posted: Wed Sep 20, 2023 10:35 am Post subject: |
|
|
Newbie
Joined: 18 Sep 2023
Posts: 5
|
Hi,
issue has been solved by adding the following lines to mqclient.ini:
| Quote: |
OCSPAuthentication=OPTIONAL
OCSPCheckExtensions=NO |
After that everything worked as expected. I still don't understand why this wasn't a problem with Java, but I learned that Java / C++ obviously work in different ways in that matter.
However ... thanks for your help! The hint from exerk was gold and helped a lot solving this issue for us. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
