MQ

 View Only

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

    Posted Fri February 24, 2023 03:22 PM
    Edited by Dominika Fri February 24, 2023 03:38 PM

    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 
    ------------------------------



  • 2.  RE: Secure handshake failing during IBM.MQ MQQueueManager on Linux .Net Managed

    Posted Sun February 26, 2023 06:20 PM

    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


  • 3.  RE: Secure handshake failing during IBM.MQ MQQueueManager on Linux .Net Managed

    Posted Mon February 27, 2023 10:25 AM
    Edited by Dominika Mon February 27, 2023 10:45 AM

     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


  • 4.  RE: Secure handshake failing during IBM.MQ MQQueueManager on Linux .Net Managed

    Posted Sun February 26, 2023 11:54 PM

    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


  • 5.  RE: Secure handshake failing during IBM.MQ MQQueueManager on Linux .Net Managed

    Posted Mon February 27, 2023 10:23 AM

    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


  • 6.  RE: Secure handshake failing during IBM.MQ MQQueueManager on Linux .Net Managed

    Posted Mon February 27, 2023 06:50 AM
    Edited by Adam Burgess Mon February 27, 2023 06:51 AM

    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


  • 7.  RE: Secure handshake failing during IBM.MQ MQQueueManager on Linux .Net Managed

    Posted Mon February 27, 2023 10:29 AM

    Do you know how I can use different cipher for handshake and different cipher for mq channel?



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

    Original Message


  • 8.  RE: Secure handshake failing during IBM.MQ MQQueueManager on Linux .Net Managed

    Posted Mon February 27, 2023 11:05 AM

    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.



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

    Original Message


  • 9.  RE: Secure handshake failing during IBM.MQ MQQueueManager on Linux .Net Managed

    Posted Mon February 27, 2023 11:19 AM

    I would perhaps try ECDHE_RSA_AES_256_GCM_SHA384 for the dotnet client, and ask the QMgr admin to use the same for SVRCONN if that does not work.



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

    Original Message