Secure handshake failing during IBM.MQ MQQueueManager on Linux .Net Managed

link管理

链接快照平台

输入网页链接，自动生成快照
标签化管理网页链接

IBM Integration Community

Trying to change CipherSpec from TLS_RSA_WITH_AES_256_CBC_SHA256 to TLS_AES_256_GCM_SHA384 . For TLS_RSA_WITH_AES_256_CBC_SHA256 I was able to connect to IBMMQ queues. After changing to TLS_AES_256_GCM_SHA384 I get error:

Interop+OpenSsl+SslException: SSL Handshake failed with OpenSSL error - SSL_ERROR_SSL. ---> Interop+Crypto+OpenSslCryptographicException: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate --- End of inner exception stack trace --- at Interop.OpenSsl.DoSslHandshake(SafeSslHandle context, ReadOnlySpan 1 input, Byte[]& sendBuf, Int32& sendCount) at System.Net.Security.SslStreamPal.HandshakeInternal(SafeFreeCredentials credential, SafeDeleteSslContext& context, ReadOnlySpan 1 inputBuffer, Byte[]& outputBuffer, SslAuthenticationOptions sslAuthenticationOptions) --- End of inner exception stack trace --- at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter](TIOAdapter adapter, Boolean receiveFirst, Byte[] reAuthenticationData, Boolean isApm) at System.Net.Security.SslStream.AuthenticateAsClient(SslClientAuthenticationOptions sslClientAuthenticationOptions) at System.Net.Security.SslStream.AuthenticateAsClient(String targetHost, X509CertificateCollection clientCertificates, SslProtocols enabledSslProtocols, Boolean checkCertificateRevocation) at IBM.WMQ.Nmqi.MQEncryptedSocket.MakeSecuredConnection()

Should I configure anything else? I will add that the app is on Linux, the connection that establishes from the .Net client is managed.

Openssl config:

CipherString = @SECLEVEL=1:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8:AES256-SHA256:!ECDHE-RSA-AES256-GCM-SHA384:!AES256-GCM-SHA384:!AES128-SHA256

Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256

TLS.MinProtocol = TLSv1.2 TLS.MaxProtocol = TLSv1.3

DTLS.MinProtocol = DTLSv1.2 DTLS.MaxProtocol = DTLSv1.2

SignatureAlgorithms = ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:ed25519:ed448:rsa_pss_pss_sha256:rsa_pss_rsae_sha256:rsa_pss_pss_sha384:rsa_pss_rsae_sha384:rsa_pss_pss_sha512:rsa_pss_rsae_sha512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224:ECDSA+SHA1:RSA+SHA1sh-4

------------------------------
Dominika
------------------------------

Can you tell us what the configuration on the SVRCONN channel is? Especially, what the SSLCIPH attribute is set to.

Additionally, you are changing from TLS_RSA_WITH_AES_256_CBC_SHA256 which is a TLS 1.2 protocol algorithm, to TLS_AES_256_GCM_SHA384 which is a TLS 1.3 protocol algorithm, so we'd be interested to know whether your queue manager has the TLS 1.3 protocol enabled. If you don't know, the answer is likely no. Have a look in the qm.ini file.

Could you also show us what the queue manager error log had to say. You have only shown us the client application side of the error. With communication problems there are always two sides to the story.

Cheers,
Morag

------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com
------------------------------

Original Message Original Message:
Sent: Fri February 24, 2023 03:21 PM
From: Dominika
Subject: Secure handshake failing during IBM.MQ MQQueueManager on Linux .Net Managed

Should I configure anything else? I will add that the app is on Linux, the connection that establishes from the .Net client is managed.

Openssl config:

Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256

TLS.MinProtocol = TLSv1.2 TLS.MaxProtocol = TLSv1.3

DTLS.MinProtocol = DTLSv1.2 DTLS.MaxProtocol = DTLSv1.2

------------------------------
Dominika
------------------------------

The configuration is weird on the server side because the server itself does not support TLS 1.3 (only TLS 1.2) for handshake, but the server side mq require the TLS_AES_256_GCM_SHA384 cipher. Can I choose a different cipher for handshake and mq? I have very limited access to server side logs. I can't see the configuration. Where can I find qm.ini file?

------------------------------
Dominika
------------------------------

Original Message Original Message:
Sent: Sun February 26, 2023 06:19 PM
From: Morag Hughson
Subject: Secure handshake failing during IBM.MQ MQQueueManager on Linux .Net Managed

Can you tell us what the configuration on the SVRCONN channel is? Especially, what the SSLCIPH attribute is set to.

Cheers,
Morag

------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com

Original Message:
Sent: Fri February 24, 2023 03:21 PM
From: Dominika
Subject: Secure handshake failing during IBM.MQ MQQueueManager on Linux .Net Managed

Should I configure anything else? I will add that the app is on Linux, the connection that establishes from the .Net client is managed.

Openssl config:

Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256

TLS.MinProtocol = TLSv1.2 TLS.MaxProtocol = TLSv1.3

DTLS.MinProtocol = DTLSv1.2 DTLS.MaxProtocol = DTLSv1.2

------------------------------
Dominika
------------------------------

Original Message Original Message:
Sent: Fri February 24, 2023 03:21 PM
From: Dominika
Subject: Secure handshake failing during IBM.MQ MQQueueManager on Linux .Net Managed

Should I configure anything else? I will add that the app is on Linux, the connection that establishes from the .Net client is managed.

Openssl config:

Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256

TLS.MinProtocol = TLSv1.2 TLS.MaxProtocol = TLSv1.3

DTLS.MinProtocol = DTLSv1.2 DTLS.MaxProtocol = DTLSv1.2

------------------------------
Dominika
------------------------------

I am using IBMXMSDotnetClient version 9.3.2. The error I get after changing the cipher is :

2059 (080B) (RC2059): MQRC_Q_MGR_NOT_AVAILABLE.

When I use the old one on the server side, a cipher mismatch error is returned (without ssl error), i.e. it shows that I used TLS_RSA_WITH_AES_256_CBC_SHA256 when I should have used TLS_AES_256_GCM_SHA384.

------------------------------
Dominika
------------------------------

Original Message Original Message:
Sent: Sun February 26, 2023 11:54 PM
From: Ram Subba Rao Chalamalasetti
Subject: Secure handshake failing during IBM.MQ MQQueueManager on Linux .Net Managed

Please note that TLS1.3 is supported in Managed MQ .NET Client only from IBM MQ v9.3.2.

------------------------------
Ram Subba Rao Chalamalasetti

Original Message:
Sent: Fri February 24, 2023 03:21 PM
From: Dominika
Subject: Secure handshake failing during IBM.MQ MQQueueManager on Linux .Net Managed

Should I configure anything else? I will add that the app is on Linux, the connection that establishes from the .Net client is managed.

Openssl config:

Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256

TLS.MinProtocol = TLSv1.2 TLS.MaxProtocol = TLSv1.3

DTLS.MinProtocol = DTLSv1.2 DTLS.MaxProtocol = DTLSv1.2

------------------------------
Dominika
------------------------------

As far as I understand it the dotnet client behaviour differs from other clients with respect to TLS. The first connection handshake agrees a TLS cipher (and protocol level), which is controlled by the openssl version and config on linux and also by the Qmgr offering (which may be reduced by the AllowedCipherSpecs parameter in its qm.ini). However, this is not related to the channel (SVRCONN) configured cipher (SSLCIPH). Once the dotnet client TLS layer agrees this pre-channel cipher it will NOT negotiate down to any lower cipher. This pre-channel cipher is not mentioned in any logs (or traces) so you just have to work this out for yourself by checking the queue manager version/config and client side openssl version/config (or use network packer TLS decoder to observe ClientHello/ServerHello content. You can also test out the pre-channel behaviour with openssl s_client -connect <host>:<port>. You can play with "-msg" and "-cipher <cipher_specnames_in_openssl_format>" and other options to mimic dotnet.

Perhaps worth considering using the non-specific SSLCIPH values of the SVRCONN e.g. "ANY_TLS12_OR_HIGHER" for channels used by dotnet.

As an aside that if you use SSLCAUTH (which as far am I concerned should be mandatory) then you should know dotnet on linux does not support friendlyname querying to locate the client private-key+certificate and IBM MQ dotnet base classes simply pick out the first one with a private key (which is quite likely to not be the one you want). For this reason I gave up with using any dotnet based MQ client - there is work in progress to address this limitation (and also to fix the docs).

------------------------------
Adam Burgess
------------------------------

Original Message Original Message:
Sent: Fri February 24, 2023 03:21 PM
From: Dominika
Subject: Secure handshake failing during IBM.MQ MQQueueManager on Linux .Net Managed

Should I configure anything else? I will add that the app is on Linux, the connection that establishes from the .Net client is managed.

Openssl config:

Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256

TLS.MinProtocol = TLSv1.2 TLS.MaxProtocol = TLSv1.3

DTLS.MinProtocol = DTLSv1.2 DTLS.MaxProtocol = DTLSv1.2

------------------------------
Dominika
------------------------------

Original Message Original Message:
Sent: Mon February 27, 2023 06:50 AM
From: Adam Burgess
Subject: Secure handshake failing during IBM.MQ MQQueueManager on Linux .Net Managed

Perhaps worth considering using the non-specific SSLCIPH values of the SVRCONN e.g. "ANY_TLS12_OR_HIGHER" for channels used by dotnet.

------------------------------
Adam Burgess

Original Message:
Sent: Fri February 24, 2023 03:21 PM
From: Dominika
Subject: Secure handshake failing during IBM.MQ MQQueueManager on Linux .Net Managed

Should I configure anything else? I will add that the app is on Linux, the connection that establishes from the .Net client is managed.

Openssl config:

Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256

TLS.MinProtocol = TLSv1.2 TLS.MaxProtocol = TLSv1.3

DTLS.MinProtocol = DTLSv1.2 DTLS.MaxProtocol = DTLSv1.2

------------------------------
Dominika
------------------------------

I think you have to more or less arrange the SVRCONN, CLNTCONN (i.e. dotnet client) to be compatible and at least at the same level as cliient side openssl as well as the QMgr supported list. As I said once you work out what openssl or dotnet agree as a cipher when connecting to the QMgr listener (i.e. prior to any SVRCONN CHANNEL selection) you can work from there, by ensuring the SVRCONN is SSLCIPH is compatible you will have to ask the QMgr admin in your case), and then finally by matching that with your dotnet application cipher. That is at least how it was when I last looked a few months back.

Should I configure anything else? I will add that the app is on Linux, the connection that establishes from the .Net client is managed.

Openssl config:

Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256

TLS.MinProtocol = TLSv1.2 TLS.MaxProtocol = TLSv1.3

DTLS.MinProtocol = DTLSv1.2 DTLS.MaxProtocol = DTLSv1.2

------------------------------
Dominika
------------------------------

Original Message Original Message:
Sent: Mon February 27, 2023 11:04 AM
From: Adam Burgess
Subject: Secure handshake failing during IBM.MQ MQQueueManager on Linux .Net Managed

------------------------------
Adam Burgess

Original Message:
Sent: Fri February 24, 2023 03:21 PM
From: Dominika
Subject: Secure handshake failing during IBM.MQ MQQueueManager on Linux .Net Managed

Should I configure anything else? I will add that the app is on Linux, the connection that establishes from the .Net client is managed.

Openssl config:

Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256

TLS.MinProtocol = TLSv1.2 TLS.MaxProtocol = TLSv1.3

DTLS.MinProtocol = DTLSv1.2 DTLS.MaxProtocol = DTLSv1.2

------------------------------
Dominika
------------------------------

Marketplace

IBM Integration Community

Come for answers, stay for best practices. All we're missing is you.

Dominika Fri February 24, 2023 03:22 PM

Morag Hughson Sun February 26, 2023 06:20 PM

Dominika Mon February 27, 2023 10:25 AM

Ram Subba Rao Chalamalasetti Sun February 26, 2023 11:54 PM

Dominika Mon February 27, 2023 10:23 AM

Adam Burgess Mon February 27, 2023 06:50 AM

Dominika Mon February 27, 2023 10:29 AM

Adam Burgess Mon February 27, 2023 11:05 AM

Adam Burgess Mon February 27, 2023 11:19 AM