MQ

 View Only
Expand all | Collapse all

Java Client and ANY_TLS12_OR_HIGHER

  • 1.  Java Client and ANY_TLS12_OR_HIGHER

    IBM Champion
    Posted Fri September 03, 2021 03:45 PM
    MQ Server is MQ 9.2.0.3
    MQ Client is MQ 9.2.0.2. A vendor product that uses the Oracle JRE and the IBM MQ classes for Java API
    SVRCONN channel on MQ server is always ANY_TLS12_OR_HIGHER

    I would like to get the client side to use ANY_TLS12_OR_HIGHER as well.

    -Dcom.ibm.mq.cfg.useIBMCipherMappings=false
    Client side Cipher Suite = TLS_RSA_WITH_AES_256_CBC_SHA256
    The above works, the channel starts and runs with this CipherSpec

    -Dcom.ibm.mq.cfg.useIBMCipherMappings=false
    Client side Cipher Suite = ANY_TLS12_OR_HIGHER
    Connection Failed: (MQRC_UNSUPPORTED_CIPHER_SUITE) MQJE001: Completion Code '2', Reason '2400'.

    Removed -Dcom.ibm.mq.cfg.useIBMCipherMappings=false
    Client side Cipher Suite = ANY_TLS12_OR_HIGHER
    Connection Failed: (MQRC_UNSUPPORTED_CIPHER_SUITE) MQJE001: Completion Code '2', Reason '2400'.

    What would you try next?

    ------------------------------
    Peter Potkay
    ------------------------------


  • 2.  RE: Java Client and ANY_TLS12_OR_HIGHER

    IBM Champion
    Posted Fri September 03, 2021 06:37 PM
    More test results

    MQ Server is MQ 9.2.0.3
    MQ Client is MQ 9.2.0.2. A vendor product that uses the Oracle JRE and the IBM MQ classes for Java API
    SVRCONN Channel on MQ server is always ANY_TLS12_OR_HIGHER

    wrapper.java.additional.NN=-Dcom.ibm.mq.cfg.useIBMCipherMappings=false
    Client Cipher Suite = TLS_RSA_WITH_AES_256_CBC_SHA256
    The above works, the channel starts and runs with this CipherSpec

    wrapper.java.additional.NN=-Dcom.ibm.mq.cfg.useIBMCipherMappings=false
    Client Cipher Suite = ANY_TLS12_OR_HIGHER
    Connection Failed: (MQRC_UNSUPPORTED_CIPHER_SUITE) MQJE001: Completion Code '2', Reason '2400'.

    wrapper.java.additional.NN=-Dcom.ibm.mq.cfg.useIBMCipherMappings=false
    Client Cipher Suite = *TLS12ORHIGHER
    Connection Failed: (MQRC_UNSUPPORTED_CIPHER_SUITE) MQJE001: Completion Code '2', Reason '2400'.

    wrapper.java.additional.NN=-Dcom.ibm.mq.cfg.useIBMCipherMappings=false
    Client Cipher Suite = "*TLS12ORHIGHER"
    Connection Failed: (MQRC_UNSUPPORTED_CIPHER_SUITE) MQJE001: Completion Code '2', Reason '2400'.


    Removed wrapper.java.additional.NN=-Dcom.ibm.mq.cfg.useIBMCipherMappings=false
    Client Cipher Suite = ANY_TLS12_OR_HIGHER
    Connection Failed: (MQRC_UNSUPPORTED_CIPHER_SUITE) MQJE001: Completion Code '2', Reason '2400'.

    Removed wrapper.java.additional.NN=-Dcom.ibm.mq.cfg.useIBMCipherMappings=false
    Client Cipher Suite = *TLS12ORHIGHER
    Connection Failed: (MQRC_UNSUPPORTED_CIPHER_SUITE) MQJE001: Completion Code '2', Reason '2400'.

    Removed wrapper.java.additional.NN=-Dcom.ibm.mq.cfg.useIBMCipherMappings=false
    Client Cipher Suite = "*TLS12ORHIGHER"
    Connection Failed: (MQRC_UNSUPPORTED_CIPHER_SUITE) MQJE001: Completion Code '2', Reason '2400'.


    wrapper.java.additional.NN=-Dcom.ibm.mq.cfg.useIBMCipherMappings=true
    Client Cipher Suite = ANY_TLS12_OR_HIGHER
    Connection Failed: (MQRC_UNSUPPORTED_CIPHER_SUITE) MQJE001: Completion Code '2', Reason '2400'.

    wrapper.java.additional.NN=-Dcom.ibm.mq.cfg.useIBMCipherMappings=true
    Client Cipher Suite = *TLS12ORHIGHER
    Connection Failed: (MQRC_UNSUPPORTED_CIPHER_SUITE) MQJE001: Completion Code '2', Reason '2400'.

    wrapper.java.additional.NN=-Dcom.ibm.mq.cfg.useIBMCipherMappings=true
    Client Cipher Suite = "*TLS12ORHIGHER"
    Connection Failed: (MQRC_UNSUPPORTED_CIPHER_SUITE) MQJE001: Completion Code '2', Reason '2400'.

    ------------------------------
    Peter Potkay
    ------------------------------



  • 3.  RE: Java Client and ANY_TLS12_OR_HIGHER

    IBM Champion
    Posted Tue September 28, 2021 04:34 PM
    The app was using a bundled version of an older MQ Client, 9.1.0.6. 
    As the wild card ciphers were not introduced until MQ 9.1.1 and 9.1.4, this MQ Client did not know what to make of the strange Cipher names I was feeding it. The MQ Client was rightly failing the connection with an appropriate MQRC.

    Once I switched to 9.2.0.2 MQ Client, all the wild cards should have worked, and they do, from an MQ perspective. What I think is occurring now is the JRE (actually OpenJDK as I dug deeper) is choking on attempts to use any wild card cipher that allows the MQ Server and Client negotiating the TLS handshake to try TLS 1.3 first. The older JRE simply does not even understand what TLS 1.3 is and aborts - the MQ Client then reports the MQRC 2009. But if I force the TLS handshake to only try TLS 1.2 (by using *TLS12) then the older JRE is able to deal with the TLS handshake because its never presented TLS 1.3.

    I need to figure out exactly what OpenJDK version supports TLS 1.3 and then see when this vendor product will ship with that version (or newer). In the meantime I will go with *TLS12 on the MQ Client side and keep ANY_TLS12_OR_HIGHER on the MQ Server side.


    ------------------------------
    Peter Potkay
    ------------------------------



  • 4.  RE: Java Client and ANY_TLS12_OR_HIGHER

    IBM Champion
    Posted Wed September 29, 2021 12:38 PM
    > I need to figure out exactly what OpenJDK version supports TLS 1.3

    For Java version 8:

    - Since 8u261-b12 from Oracle JDK: https://www.oracle.com/java/technologies/javase/8u261-relnotes.html
    - Since 8u262-b10 from AdoptOpenJDK (Eclipse Adoptium)

    Crypto road map: https://java.com/en/jre-jdk-cryptoroadmap.html

    Or you can just go straight to OpenJDK 11 which has TLS 1.3 support right from day zero.

    Some user blog posting about TLS 1.3:
    - https://www.petefreitag.com/item/918.cfm
    - https://blog.gypsyengineer.com/en/security/an-example-of-tls-13-client-and-server-on-java.html

    later
    Roger

    ------------------------------
    Roger Lacroix
    CTO
    Capitalware Inc.
    London ON
    226-980-7307
    ------------------------------



  • 5.  RE: Java Client and ANY_TLS12_OR_HIGHER

    IBM Champion
    Posted Thu September 30, 2021 07:50 PM
    Thanks Roger. I think I'm stuck using some older Java version even though I see folders for /jre/jdk-13.0.1 and .jre/jdk-14.0.2 in the install path of this product.

    java -version

    openjdk version "1.8.0_282"

    OpenJDK Runtime Environment (build 1.8.0_282-b08)

    OpenJDK 64-Bit Server VM (build 25.282-b08, mixed mode)


    I don't see anything about a version starting with 8u26**-b1* in that output.

    Java, still a 4 letter word to me after all these years.

    ------------------------------
    Peter Potkay
    ------------------------------



  • 6.  RE: Java Client and ANY_TLS12_OR_HIGHER

    IBM Champion
    Posted Thu September 30, 2021 10:07 PM
    - 8u262-b10 is called the "short form" version
    - 1.8.0_282-b08 is called the "long form" version

    If you really want to read about it, you can find a nice long explanation here: https://openjdk.java.net/jeps/223

    You are using "OpenJDK Runtime Environment (build 1.8.0_282-b08)" which is higher than 8u262-b10 (aka 1.8.0_262).  Hence, it will have TLS 1.3 support.

    > I see folders for /jre/jdk-13.0.1 and .jre/jdk-14.0.2

    You should get rid of Java 13 & Java 14 because they are no longer supported (short-term releases).  You should only be using Java 8 or 11 or 17.  Those 3 are LTS releases.

    later
    Roger

    ------------------------------
    Roger Lacroix
    CTO
    Capitalware Inc.
    London ON
    226-980-7307
    ------------------------------



  • 7.  RE: Java Client and ANY_TLS12_OR_HIGHER

    IBM Champion
    Posted Fri October 01, 2021 08:45 AM
    Having all those versions on your server, did you check the value of the JAVA_HOME (jdk) and JRE_HOME (jre) environment variables for the process starting your java app?

    Does the startup of that process use those variables like ${JAVA_HOME}\bin\java[w] ... + arguments ?

    ------------------------------
    Francois Brandelik
    ------------------------------



  • 8.  RE: Java Client and ANY_TLS12_OR_HIGHER

    IBM Champion
    Posted Tue October 19, 2021 10:39 AM
    Thanks all for the replies, both public and private.   The saga continues. I do have it working with the client side using *TLS12 and the SVRCONN using ANY_TLS12_OR_HIGHER. As soon as I change the client to use *TLS12ORHIGHER its now consistently failing with MQRC 2009. And in the queue manager log I see what looks like evidence that the client (a vendor product) is sending their vendor self signed cert. The queue manager sees the client sending their cert and tries the validate it. And fails since we are not set up for the client's self signed cert nor will we be - we have SSLCAUTH(OPTIONAL).  

    Is this true? If you have SSLCAUTH(OPTIONAL) but the client sends their cert anyway, the queue manager acts on it?
    It does seems like the vendor app decides to send their client side cert if its told to use *TLS12ORHIGHER, but it doesn't send its client side cert when told to use *TLS12. The Case is pending with the vendor.


    ------------------------------
    Peter Potkay
    ------------------------------



  • 9.  RE: Java Client and ANY_TLS12_OR_HIGHER

    IBM Champion
    Posted Tue October 19, 2021 04:47 PM
    Hi Peter,

    Yes, that's correct. If the client sends a certificate the queue manager always attempts to validate it. That's why the keyword is SSLCAUTH(OPTIONAL) rather than SSLCAUTH(NO). The optional setting means that the queue manager is OK with no certificate being sent, but if one is sent it will always try to validate it.

    Cheers,
    Morag

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



  • 10.  RE: Java Client and ANY_TLS12_OR_HIGHER

    Posted Wed October 20, 2021 09:01 AM
    With a Java TLS client, I have found that the trust certs that the queue manager sends in the TLS handshake will be a factor on if the Java client sends its personal certificate. So if the Java client does not receive any trust certs that that would be applicable for its personal certificate, the Java client will not send its certificate to the queue manager (since it does not have the proper trust certs to trust it).

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



  • 11.  RE: Java Client and ANY_TLS12_OR_HIGHER

    IBM Champion
    Posted Tue November 30, 2021 11:30 AM
    My case with the vendor hit a dead end.

    I've opened a Case with IBM.

    It does seem that when the only change is on the client side toggling between *TLS12 and *TLS12ORHIGHER it is changing the client's behavior.

    The server side is MQ 9.2.0.3 with *TLS12ORHIGHER with SSLCAUTH(OPTIONAL). This does not change as I test.
    The client side is MQ 9.2.0.2, Java app. 
    With the client specifying *TLS12, the connection works.
    Changing the client side to use *TLS12ORHIGHER causes it to send its client cert (a self signed cert provided by the vendor) and the Queue Manager correctly rejects it because we are not setting ourselves up to accept a self signed cert. We don't want the client to send any cert, self signed or not. We are using Capitalware's MQAUSX for authenticating the client so don't need the client's cert for authentication.

    If both ends are *TLS12ORHIGHER, the initial SSL handshake must be at TLS 1.3 and the question for me is why is this causing the Java MQ Client to push its client's cert.

    Peter





    ------------------------------
    Peter Potkay
    ------------------------------



  • 12.  RE: Java Client and ANY_TLS12_OR_HIGHER

    Posted Tue November 30, 2021 12:12 PM
    Edited by Tim Zielke Tue November 30, 2021 12:14 PM
    This does sounds like a potential bug at the JSSE (Java TLS client side) level. A JSSE TLS handshake trace should be able to tell what is going on. If the MQ TLS server does not send a trust cert that is applicable for the Java client side cert when the MQ TLS server sends the client certificate request in the TLS handshake, the Java client side is supposed to send an empty client certificate reply back to the MQ TLS server side. It sounds like this is not happening, and instead the client cert is being sent back. 

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