Search code examples
sslibm-mq

MQ client (amqputc) getting "MQCONNX ended with reason code 2393" when connecting TLS enabled queue

Want to check what is wrong with my configuration.

  1. Installed the MQ and created the queue using mq-dev-config.mqsc.

  2. created a root, server and a client certificate for enabling TLS.

  3. I am using the DEV.APP.SVRCONN channel.

  4. Created the certificates in /var/mqm/qmgrs/QM1/ssl location and added all three certificates (server, client and root) in it.

  5. After restart, the queue manager is picking the location and i can see the SSLKEYR(/var/mqm/qmgrs/QM1/ssl/key) and CERTLABL(ibmwebspheremqqm1) pointing correctly.

  6. below are the channel side changes

    • Altered the DEV.APP.SVRCONN to use SSLCIPH(ANY_TLS12) SSLCAUTH(OPTIONAL) CERTLABL('')
    • removed CONNAUTH at queue manager
    • Added back-stop channel authentication rule
    • Allow connection if it match (SSLPEER('CN=mqclient,O=mq,C=us') SSLCERTI('CN=ca-rootca'))

  7. I am able to connect the queue using java client.

  8. When using amqputc, i am getting the error

    AMQ9636E: SSL distinguished name does not match peer name, channel 'DEV.APP.SVRCONN'

CCDT file, mqclient.ini file, channel CHLAUTH settings is in the below screenshot:

enter image description here

enter image description here

enter image description here

Solution

  • When connecting an MQ Client application, e.g. amqsputc, to a queue manager using mutual TLS there is a certificate at each end and there can be a peer name check at each end.

    A peer name check is when you supply a pattern to match against the certificate Distinguished Name (DN) to ensure that you are indeed communicating with the correct entity. While a certificate may be supplied that is valid, you might want to go one step further and ensure that this is a certificate that identifies the correct entity.

    Queue Manager side

    To have the queue manager end of the channel check the client's certificate's DN, you supply this pattern either on the SVRCONN channel definition or in a CHLAUTH rule (preferred).

    So assuming the client certificate DN is CN=mqclient, we would imagine a CHLAUTH rule something like:-

    SET CHLAUTH(DEV.APP.SVRCONN) TYPE(SSLPEERMAP) +
    SSLPEER('CN=mqclient') +
    USERSRC(MAP) MCAUSER('clntusr')

    If the client presented a certificate to the queue manager with a DN containing CN=mqclient then it would be allowed to run and would be assigned to run with the user id of clntusr.

    Client side

    To have the client end of the channel check the queue manager's certificate's DN, you supply this pattern on the CLNTCONN definition in the CCDT.

    So assuming the queue manager certificate DN is CN=mqserver, we would imagine a CLNTCONN definition something like:-

    DEFINE CHANNEL(DEV.APP.SVRCONN) CHLTYPE(CLNTCONN) +
       CONNAME('edx2(1414)') SSLCIPH(ANY_TLS12) +
       SSLPEER('CN=mqserver')

    If the queue manager presented a certificate to the client with a DN containing CN=mqserver then the connection would be allowed to proceed.

    If, however, you mix these up, and say, code SSLPEER('CN=mqclient') in your client side CCDT, then the match is going to fail, and error message AMQ9636E will be reported.

    If they simply don't match because you coded SSLPEER('CN=server') in your client side CCDT and the queue manager presented a certificate with a DN containing CN=mqserver then error message AMQ9636E will also be reported.