PH49586: DEFINE CHANNEL WITH OLD TLS 1.0 CIPHERSPEC REQUIRES TLS10ON DD DUMMY BUT QMINI HAS ALLOWEDCIPHERSPECS=ALL

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• When a channel is defined and the SSLCIPH parameter specified,
  or when a channel with a non-empty SSLCIPH field is altered,
  then the SSLCIPH field is validated in CSQMCNAC. One of the
  validation checks performed is whether the TLS protocol
  associated with the MQ Cipher specification is enabled. The
  check for whether a TLS protocol is enabled only takes into
  account the TLS DD statements and certain CHINIT service parms.
  
  In the customer's case, they are not using the TLS10ON DD
  statement, but have instead allowed the use of the TLS 1.0
  protocol by setting AllowedCipherSpecs=all in their QMINI data
  set. This has resulted in message CSQX695I being issued during
  CHINIT startup signifying that the TLS 1.0 protocol can be used.
  
  With this configuration, the TLS 1.0 protocol has been enabled
  on the SSL sockets, and thus receiver and sender channels will
  be able to start and run successfully. If TLS 1.0 channels are
  able to be started in this configuration, then it makes sense
  that they should be able to be defined or altered as well.
  
  Until this APAR is ready, if the customer needs to alter or
  define any channels which are using a TLS1.0 Cipher
  specification, then they will need to use the TLS10ON DD
  statement.
  
  The SSLCIPH field is validated even when the SSLCIPH parameter
  isn't specified on an ALTER CHANNEL(), DEFINE CHANNEL() LIKE or
  DEFINE CHANNEL() QSGDISP(COPY) command. In this case however,
  the command will be rejected without issuing message CSQM102E.
  
  This is an additional code defect in CSQMCNAC and will be
  corrected as part of this APAR.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of IBM MQ for z/OS Version 9       *
  *                 Release 2 Modification 0 and Release 3       *
  *                 Modification 0                               *
  ****************************************************************
  * PROBLEM DESCRIPTION: After migrating from V900 to V920, it   *
  *                      is possible for the command DEFINE      *
  *                      CHANNEL(...) CHLTYPE(SVRCONN) QSGDISP   *
  *                      (COPY) REPLACE to fail with reason      *
  *                      00D44004.                               *
  ****************************************************************
  The DEFINE CHANNEL(...) CHLTYPE(SVRCONN) QSGDISP(COPY) REPLACE
  command was being applied to a channel which had a SSLCIPH
  field containing a TLS1.0 cipher. The code which handles the
  validation of the SSLCIPH field was ignoring that a TLS1.0
  cipher had been enabled in the QMINI and was only checking for
  the TLS10ON DD card.
  

Problem conclusion

• The code has been changed to check the QMINI as well as the DD
  card for allowed ciphers so the DEFINE CHANNEL(...) CHLTYPE
  (SVRCONN) QSGDISP(COPY) REPLACE command no longer fails with
  reason 00D44004 if the cipher has been specified in the QMINI.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Modules/Macros

• CSQMCNAC
  

Fix information

• Fixed component name

  IBM MQ Z/OS V9

• Fixed component ID

  5655MQ900

Applicable component levels

• R200 PSY UI90177

     UP23/02/04 P F302

• R300 PSY UI90176

     UP23/02/04 P F302

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.