MQ

 View Only
Expand all | Collapse all

Cipher causing mq to check for ICSF

  • 1.  Cipher causing mq to check for ICSF

    Posted Thu March 24, 2022 09:14 AM
    Hi all
    I have a mq client using .NET    trying to connect to z/os mq
    we believe we have each side configured properly.
    when we try to connect using cipher TLS_RSA_WITH_AES_256_CBC_SHA256
    we get z/os mq error...

    +CSQX629E MQS1 CSQXRESP Channel ???? requires ICSF for SSLCIPH(????)

    any help appreciated

    Tom



    ------------------------------
    Tom Taylor
    ------------------------------


  • 2.  RE: Cipher causing mq to check for ICSF

    IBM Champion
    Posted Thu March 24, 2022 09:24 AM
    Edited by Luc-Michel Demey Thu March 24, 2022 09:25 AM
    Hello,
    From  : https://www.ibm.com/docs/en/ibm-mq/9.1?topic=zos-distributed-queuing-messages-csqx
    CSQX629E

    csect-name Channel channel-name requires ICSF for SSLCIPH(ciph)

    Severity Explanation

    Channel channel-name is using a cipherspec ciph that requires Integrated Cryptographic Service Facility (ICSF) callable services, but ICSF is not available. Sometimes the channel name and cipherspec are unknown and so are shown as "????".

    HTH, LMD.

    ------------------------------
    Luc-Michel Demey
    DEMEY CONSULTING
    lmd@demey-consulting.fr
    #IBMChampion
    ------------------------------



  • 3.  RE: Cipher causing mq to check for ICSF

    Posted Thu March 24, 2022 09:30 AM
    Tom,

    Do you have ICSF up on your z/OS system?  If so, do you have any master keys in the crypto engine?

    If you do not have ICSF up, you'll need to work on getting it up and running, before you can use those ciphers on z/OS.

    ------------------------------
    Peter Vander Woude
    ------------------------------



  • 4.  RE: Cipher causing mq to check for ICSF

    IBM Champion
    Posted Thu March 24, 2022 04:36 PM
    As it says in the description of error message CSQX629E, "The cipherspecs that use GCM or ephemeral elliptic curve algorithms require ICSF." You say that you are receiving this error when trying to use CipherSpec TLS_RSA_WITH_AES_256_CBC_SHA256 which is not one of those CipherSpecs.

    This suggests to me that your setup on the .NET side might not be presenting the CipherSpec you think it is and that we should look into that further. Could you tell us more about that setup please?

    Cheers,
    Morag

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



  • 5.  RE: Cipher causing mq to check for ICSF

    Posted Thu March 24, 2022 04:48 PM
    So..

    It has been determined thru SSL traces on the Mainframe , that when cipher negotiations occur, The mainframe will use a cipher that is on the clients cipher list... in this case,,, a cipher that is higher then what both sides have specified is being used.... This cipher requires ICSF on the mainframe,,,which we do not have running and thus we get the error.

    They have tried to disable all ciphers on the windows client except for the one we want to use (TLS_RSA_WITH_AES_256_CBC_SHA256)  but this seems not to have any effect.



    Tom

    ------------------------------
    Tom Taylor
    ------------------------------



  • 6.  RE: Cipher causing mq to check for ICSF

    IBM Champion
    Posted Thu March 24, 2022 11:56 PM

    What you say makes sense. That is indeed how cipher negotiation works. So to help you further, can you expand on how you have attempted to disable all the ciphers on the windows client except for the one you want? You mentioned already in your initial post that this is .NET, but is it fully managed .NET or non-managed .NET. This is an important piece of information since there are two different TLS implementations for these two environments.

    Perhaps you could also show us how you are setting the CipherSpec? I'm guessing this is fully managed .NET (because in non-managed you just set one CipherSpec and it just gets used). In the fully managed .NET case there are three different ways to set the CipherSpec (see CipherSpec support for the managed .NET client). Again I'm guessing you might be using the Windows group policy since that is the only way to set a list? If you use either of the other ways shown in that link, you will only send the one you mention.

    Anyway, if you want extra assistance, let us know some of the above details so we can help further.

    Cheers,
    Morag



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



  • 7.  RE: Cipher causing mq to check for ICSF

    Posted Fri March 25, 2022 03:28 AM
    I don't think there is a way in a managed .NET client to specify a cipher. NET actually passes a list of ciphers to MQ and the QM picks the cipher based on a pre-defined order. According to https://www.ibm.com/docs/en/ibm-mq/9.2?topic=cipherspecs-cipherspec-order-in-tls-handshake

    You can change this list so that MQ will prioritize the right one  https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.2.0/com.ibm.mq.sec.doc/q134760_.html

    Look at the heading: Providing a custom list of ordered and enabled CipherSpecs on IBM MQ for Multiplatforms



    ------------------------------
    Daniel Nordkvist
    ------------------------------



  • 8.  RE: Cipher causing mq to check for ICSF

    IBM Champion
    Posted Fri March 25, 2022 05:08 AM
    It would certainly seem appropriate to only enable the list of cipherspecs on the z/OS queue manager that you are able to support, i.e. not those which require ICSF, but it should be equally possible to configure the .NET client to send up a shorter list (including a list of length 1) in order to be certain of which cipher spec will get chosen for the channel to run. If you're sending up a list of ciphers when using the .NET fully managed client, you would need to use one of the SSLCIPH(ANY*) values so that the channel is happy to run at all.

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



  • 9.  RE: Cipher causing mq to check for ICSF

    Posted Fri March 25, 2022 06:19 AM
    On Linux managed .NET there is no way to specify a cipher the one you specify in the connectionfactory is just ignored from what I have seen. Maybe windows handles it different.

    ------------------------------
    Daniel Nordkvist
    ------------------------------



  • 10.  RE: Cipher causing mq to check for ICSF

    Posted Fri March 25, 2022 06:38 AM

    The cipher set in the application is only used to determine the TLS version. On Windows .NET uses the list of ciphers specified in the Windows Group policy.

    On Linux, .NET uses OpenSSL for TLS communication. Following link has some information on how to set the ciphers on Linux for .NET Core applications

    https://docs.microsoft.com/en-us/dotnet/core/compatibility/cryptography/5.0/default-cipher-suites-for-tls-on-linux



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



  • 11.  RE: Cipher causing mq to check for ICSF

    Posted Fri March 25, 2022 08:51 AM
    HI All

    First ...thank you for all your input.   Second.. I'm Mainframe based so windows is not my forte, but i do understand all your input. The app is MANAGED .NET.  The code below is taken directly from IBM doc.  Level 2 has reviewed and they see no issue with it.. we have tried under java and have no issues.  as you can read, the cipher is being set,but then apparently ignored. 

     connectionProperties.Add(MQC.HOST_NAME_PROPERTY, "ACMEHOST4");

                        connectionProperties.Add(MQC.PORT_PROPERTY, 1400);

                        connectionProperties.Add(MQC.CHANNEL_PROPERTY, "MQT1.CLNTCONN.AZMP");

                        connectionProperties.Add(MQC.SSL_CIPHER_SPEC_PROPERTY, "TLS_RSA_WITH_AES_256_CBC_SHA256");

                        connectionProperties.Add(MQC.SSL_CERT_STORE_PROPERTY, "*USER");

     

                        connectionProperties.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_MANAGED);

     

    MQEnvironment.CertificateLabel = "MQT1-AZ.acme.com";

     

    Tom

    ------------------------------
    Tom Taylor
    ------------------------------



  • 12.  RE: Cipher causing mq to check for ICSF

    Posted Fri March 25, 2022 09:07 AM

    If you look into the AMQERR-log it should point out what is expected. 

    For me this solved the problem(as I mentioned earlier)

    You can change this list so that MQ will prioritize the right one  https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.2.0/com.ibm.mq.sec.doc/q134760_.html

    Look at the heading: Providing a custom list of ordered and enabled CipherSpecs on IBM MQ for Multiplatforms



    ------------------------------
    Daniel Nordkvist
    ------------------------------



  • 13.  RE: Cipher causing mq to check for ICSF

    Posted Fri March 25, 2022 01:14 PM
    You may also want to look into running ICSF. TLS_RSA_WITH_AES_256_CBC_SHA256 is a static RSA CipherSuite that is no longer allowed at TLS 1.3, because it does not support forward secrecy. The CipherSuites (there are only 5 of them) at TLS 1.3 all use ephemeral keys to exchange the pre-master secret in the handshake, and one of the common algorithms used is ECDHE which includes elliptical curves. Of the 5 CipherSuites at TLS 1.3, two of them use GCM. As you inevitably move to the requirement of having to be at TLS 1.3, you are more than likely going to need ICSF.

    ------------------------------
    Tim Zielke
    ------------------------------