MQ

 View Only
Expand all | Collapse all

Problems with SSL

  • 1.  Problems with SSL

    Posted Wed September 09, 2020 02:56 PM


    Hello everyone!

    Two months ago I started at a new company and one of my first "real/big" tasks have been setting up IBM MQ for messaging. I have set up singe node with basic configuration in our test environment (when messages are coming through, I will continue to set up failover).

    The problem we have with our first client (who sends us messages) is that, when pinging channel, they recieve error: AMQ9638E: SSL communications error for channel '***********'.

    From logs I only see also very unclear messages: 

    AMQ9638E: SSL communications error for channel '***********' EXPLANATION: An unexpected SSL communications error occurred for a channel, as reported in the preceding messages. The channel is '***********'; in some cases its name cannot be determined and so is shown as '????'. The channel did not start. ACTION: Investigate the problem reported in the preceding messages. Review the local and remote console logs for reports of network errors. Correct the errors and restart the channel.


    Our partner sent us Intermediate and Root certificate which I added to our qmgr keystore. Just for clarity, I will add the commands:

    runmqakm -cert -add -db key.kdb -stashed -file root_cert.txt -label "GlobalSign Root CA - R3" runmqakm -cert -add -db key.kdb -stashed -file Intermediate_cert.txt -label "GlobalSign nv-sa"


    Am I doing something wrong? Like I said, I just started with IBM MQ from zero and doesnt have any experience with it. I have been going over the docs continuously to learn and get up to speed.

    Other thing is that  I set up "playground" to my localhost (one server for sending messages and other two for recieving). When I generate self-signed certificates, extract and add them to valid keystore, I get the same errors. When I disable SSL for channels, messages are coming through.

    Will post the certificate process once again:

    On SDR node runmqckm -cert -create -db key.kdb -stashed -label ibmwebspheremqtest -dn "CN=MANO, O=ABC, C=US" -size 2048 -x509version 3 -expire 365 runmqckm -cert -extract -db key.kdb -stashed -label ibmwebspheremqtest -target test.arm -format ascii On RCVR node runmqckm -cert -add -db key.kdb -stashed -label ibmwebspheremqtest -file test.arm -format ascii


    Can anyone tell, am I doing something wrong?

    Thanks



    ------------------------------
    Kristjan Voolaid
    ------------------------------


  • 2.  RE: Problems with SSL

    IBM Champion
    Posted Thu September 10, 2020 01:15 AM
    Hi Kristjan,

    From your last certificate process paragraph, it looks as though you are creating a certificate for your sender queue manager, but not creating a certificate for the receiver.

    This is going to fail because of the asymmetry of the TLS connection process.

    TLS requires that the SERVER side (in MQ this is the RECEIVER channel) must have a certificate/key pair (a personal certificate). So you need to create a personal certificate for the queue manager which has the receiver channel.

    If you specify in the receiver channel configuration the option SSLCAUTH(REQUIRED), then the sender channel queue manager ALSO has to have a ceritifcate/key pair.

    So, your two queue managers have 2 different names. QM1 and QM2. They will each host sender and receiver channels between the 2 queue managers.

    You need to create certs for each qmgr in their own keystore, extract and exchange them, and then add the certs into the partner QM keystore. 

    Then you have to either restart the queue manager or issue the runmqsc command "refresh security(*) type(ssl)". This is because MQ caches the keystore in memory and you have to tell it to flush the cached copy and reload it.

    Then in the channel definitions of the SENDER channel, you should include SSLCIPH to pick a cipher (or a cipher group like ANY_TLS12) and put the DN of the RECEIVER queue manager in the SSLPEER. You can also use CHLAUTH records of type SSLPEERMAP to validate the SSLPEER, which has the advantage of allowing you to validate the certificate issuer as well.

    The receiver channel is a mirror image of the sender. It must have a compatible cipher (the same one or a member of the group named by the partner, or a group which includes the cipher set in the partner). The SSLPEER should be the DN of the sender channel QM certificate.

    I hope that helps.

    Regards,

    ------------------------------
    Neil Casey
    Senior Consultant
    Syntegrity Solutions
    Melbourne, Victoria
    IBM Champion (Cloud) 2019-20
    +61 (0) 414 615 334
    ------------------------------



  • 3.  RE: Problems with SSL

    Posted Thu September 10, 2020 04:20 AM
    Edited by Kristjan Voolaid Thu September 10, 2020 04:22 AM

    First of all, thanks for the answer!

    So I managed to get my "playground" working with SSL. Created personal certificate to RECEIVER qmgr, extracted and added it to SENDER keystore. Messages are coming through now!


    But as for connecting partners to or MQ - me as RECEIVER, I have to request personal certificate, send CSR to CA, receive certificates, add them to our keystore, send Intermediate and Root certificate to our parnter and set up also a SENDER channel? (Just going over the steps to get things done correctly)

    Thanks again!



    ------------------------------
    Kristjan Voolaid
    ------------------------------



  • 4.  RE: Problems with SSL

    IBM Champion
    Posted Thu September 10, 2020 07:54 PM
    Hi Kristjan,

    You are very welcome. Helping one another is what this community is about.

    Well done on getting your playground TLS connectivity working. That's a critical first step completed.

    Your description of next steps is close to right, although there is one point I try to make to my customers about establishing trust using a public CA.

    The owner of the certificate (you) should NOT provide the CA trust chain (at least not the root CA cert) to the intended recipient. How do they know that you are supplying them with a valid root cert, and not some fake? If you supply the root CA cert to them, you may as well skip the signing part and supply them with a self-signed certificate. The level of actual trust established is the same unless they actually validate the root CA certificate you send them.

    So, you need to agree with your partners whether you will use a publicly signed cert or a self-signed cert. If you get a certificate signed by a public CA, you should inform your partners which CA signed your certificate. It should then be their responsibility to source the root (and intermediate/issuer) ca certs from the CA directly.

    Similarly, you should obtain your own copies of the CA chain certificates used to sign your partners' certificates, rather than using the ones supplied by them (at least for the root CA cert).

    Creating a SENDER channel will only be necessary if you are going to be sending MQ messages to your partner organisation. If the message flow is strictly one-way, then you won't need a sender channel. This could be the case for example where your partner sends you persistent messages (datagrams) with notifications that you act on. Perhaps they are requests for quotations. You then draw up a quote and use email (or a phone call) to send it to them. There is 2 way communication, but MQ is only involved in the initial notification path.

    Regards,

    ------------------------------
    Neil Casey
    Senior Consultant
    Syntegrity Solutions
    Melbourne, Victoria
    IBM Champion (Cloud) 2019-20
    +61 (0) 414 615 334
    ------------------------------



  • 5.  RE: Problems with SSL

    Posted Wed April 10, 2024 03:36 PM

    Hi Neil,   

    We are running into a similar situation, and my google search for the error code AMQ9638E brought me here.  However, I am encountering this issue with an MQ Client trying to connect to queue manager.   In this case the recevier (qmgr) has all the necessary certs it needs for itself, I suspect there is an issue on the Client side but not able to put my finger on it.

    Thanks,

    David 



    ------------------------------
    ----------------------------------------------------------------------
    David Awerbuch
    MQ admin, MQ developer, MQ firefighter, real firefighter.
    ------------------------------



  • 6.  RE: Problems with SSL

    IBM Champion
    Posted Wed April 10, 2024 05:27 PM

    Hi David,

    I suspect you're right. According to this support doc you should figure out why the client application ended abruptly.

    Cheers,

    Morag



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



  • 7.  RE: Problems with SSL

    IBM Champion
    Posted Wed April 10, 2024 06:57 PM

    Hi David,

    Further to Morag's response, I'd recommend checking the AMQERR01.LOG on the client end. If that doesn't provide any information, you might need to activate TLS or application tracing.

    Regards,



    ------------------------------
    Neil Casey
    Senior Consultant
    Syntegrity Solutions
    Melbourne, Victoria
    IBM Champion (Cloud) 2019-22
    ------------------------------



  • 8.  RE: Problems with SSL

    IBM Champion
    Posted Thu April 11, 2024 03:16 AM
    The comment said

    You need to create certs for each qmgr in their own keystore, extract and exchange them, and then add the certs into the partner QM keystore. 

    You would do better to have a Certificate Authority rather than self signed certificates.  This avoids having to exchange certificates (which does not scale).

    When a signed certificate is sent to the remote end as part of the handshake, it is validated by the CA public certificate in the remote end's keystore.
    With a self-signed, the remote end needs a copy of the local end's public certificate .

    Colin









  • 9.  RE: Problems with SSL

    IBM Champion
    Posted Thu April 11, 2024 04:34 AM

    Hi David,

    If you do not want to specify the certificate label to be used to connect to MQ, the client certificate should have the name ibmwebspheremq<userid> with the userid of the user running the mq process.

    Otherwise you'd have to look at specifying the certlabel, perhaps in the CCDT.

    Hope it helps



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



  • 10.  RE: Problems with SSL

    Posted Fri April 12, 2024 11:45 AM
    Edited by Tim Zielke Mon April 15, 2024 11:37 AM

    Hi David,

    If your IBM MQ client application is Java, this blog post helps explain how to run and analyze a JSSE (basically a TLS) trace on the client side.

    https://community.ibm.com/community/user/integration/blogs/tim-zielke1/2020/06/10/java-jsse-debug-trace

    Thanks,

    Tim



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



  • 11.  RE: Problems with SSL

    Posted Mon April 15, 2024 07:20 PM

    Hi Tim, Thanks for the informative article

    - and FJ for your additional insight. 

    I have forwarded this to the developers for their review.

    David A.



    ------------------------------
    ----------------------------------------------------------------------
    David Awerbuch
    MQ admin, MQ developer, MQ firefighter, real firefighter.
    ------------------------------



  • 12.  RE: Problems with SSL

    IBM Champion
    Posted Fri April 12, 2024 02:31 PM

    To add to what Tim said, it may also be important to simply list the CipherSuites that the JVM is aware of and can use.

    I wrote a blog posting about some code that I found a while ago and tweaked it to list the CipherSuites available to the JVM here.

    later

    Roger



    ------------------------------
    Roger Lacroix
    CTO
    Capitalware Inc.
    London ON Canada
    https://capitalware.com
    ------------------------------



  • 13.  RE: Problems with SSL

    Posted 2 days ago

    hello,
    Following

    TISEC Tecnologia, Empresa de TI

    Thank's



    ------------------------------
    Eduardo Mansano
    ------------------------------