Thursday, November 17, 2016

Weak or broken cipher spec's are blocked - PTF UI29471 - MQ V8.0

Let's talk about cipher spec's......

For MQ V8 on z/OS...a PTF was released (UI29471 - Oct. 8th 2015) that when installed...will prohibit the use of weak or broken ciphers as well as SSLv3.

The following ciphers will be affected:

RC4_SHA_US                 (SSL 3.0)
RC4_MD5_US                 (SSL 3.0)
TRIPLE_DES_SHA_US          (SSL 3.0)
RC4_MD5_EXPORT             (SSL 3.0)
RC2_MD5_EXPORT             (SSL 3.0)
DES_SHA_EXPORT             (SSL 3.0)
NULL_SHA                   (SSL 3.0)
NULL_MD5                   (SSL 3.0)
TLS_RSA_WITH_DES_CBC_SHA   (TLS 1.0)

In order to check if you have any of these ciphers running in your z/OS environment, the following commands can be issued:

DISPLAY CHL(*) WHERE(SSLCIPH EQ RC4_SHA_US)
DISPLAY CHL(*) WHERE(SSLCIPH EQ RC4_MD5_US)
DISPLAY CHL(*) WHERE(SSLCIPH EQ TRIPLE_DES_SHA_US)
DISPLAY CHL(*) WHERE(SSLCIPH EQ RC4_MD5_EXPORT)
DISPLAY CHL(*) WHERE(SSLCIPH EQ RC2_MD5_EXPORT)
DISPLAY CHL(*) WHERE(SSLCIPH EQ DES_SHA_EXPORT)
DISPLAY CHL(*) WHERE(SSLCIPH EQ NULL_SHA)
DISPLAY CHL(*) WHERE(SSLCIPH EQ NULL_MD5)
DISPLAY CHL(*) WHERE(SSLCIPH EQ TLS_RSA_WITH_DES_CBC_SHA)


In the event that you have one of these installed and still want to install the current set of z/OS MQ maintenance....there is a work around.

To allow weak cipher spec's, the following DD statement can be added to your CHIN address space PROC:

//CSQXWEAK  DD DUMMY

To allow SSLv3 based cipher spec's, the following DD statement can be added to you CHIN address space:

//CSQXSSL3  DD DUMMY

If you are wanting to allow both weak as well as SSLv3 ciphers, both of these DD statements need to be added to the CHIN PROC.

Once these have been added, and your channel initiator has been restarted....you will see the following messages in the JESOUT:

CSQX691I +MQQM CSQXSSLI Cipher specifications based on the SSLv3 protocol are enabled    
                                                
CSQX693I +MQQM CSQXSSLI Weak or broken SSL cipher specifications are enabled  


Please remember.....it is better to get all of your channels using the current stronger ciphers, but it some cases with older version of MQ...using these cannot be avoided.

Happy messaging!!

Wednesday, March 16, 2016

WebSphere MQ Version 8, z/OS 8 byte log RBA - Converting your bootstraps.

In previous versions of WebSphere MQ, the LOG RBA was limited to 6 bytes, leaving enterprises to monitor the RBA so as not to exhaust the RBA and have the queue manager crash.  In order to reset the RBA, new bootstraps and logs needed to be allocated followed by running the CSQUTIL program using the RESETPAGE FORCE option.

Now, with version 8, the RBA has been extended to 8 bytes, virtually eliminating the possibility of running out of RBA log range.  Using a 6 byte RBA gave us a 256 terabyte log range. Now, with 8 bytes, we have 16 exabytes of log range, or 64K times more.  A queue manager running at 100MB per second, would take over 5000 years to run out of RBA log range.

So how do we convert to the 8 byte RBA.  If you are a standalone queue manager, you just need to be on MQ version 8 running in the NEWFUNC OPMODE.  If you are a queue manager running in a Queue Sharing Group (QSG), all of the members of the QSG need to be running version 8 using the NEWFUNC OPMODE.

Steps to convert your bootstrap to version 2 (8 byte):

1.) Stop queue manager cleanly.

2). Allocate a new bootstrap or set of bootstrap data sets using a different name than the currently used by the queue manager..

3). Run the CSQJUCNV conversion utility using the correct PARM.

      Standalone Queue Manager:
           PARM=('NOQSG')
      Queue Sharing Group Queue Manager:
           PARM=('INQSG,QSGroupName,DataSharingGroupName,DB2Member')

4). Rename the current bootstraps to another name...i.e. V1.

5). Rename the new V2 bootstraps to the names used by the queue manager.

6). Start the queue manager.

7). Verify that the new RBA range is shown in the JES.

    CSQJ034I <MQM1 CSQJW007 END OF LOG RBA RANGE IS FFFFFFFFFFFFFFFF

    The previous message showed the RBA as 0000FFFFFFFFFFFF

Below is some sample JCL using just a single bootstrap dataset.

Step 1: Allocate a new bootstrap with a different name:

//STEP1   EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
 DELETE (COM.MQM1.V8.BSDS01)   <=== NOTICE V8, New name
    DEFINE CLUSTER                          -
           (NAME(COM.MQM1.V8.BSDS01)        -
            VOLUMES(DCPSMS)                 -
            UNIQUE                          -
            SHAREOPTIONS(2 3) )             -
        DATA                                -
           (NAME(COM.MQM1.V8.BSDS01.DATA)   -
            RECORDS(850 60)                 -
            RECORDSIZE(4089 4089)           -
            CONTROLINTERVALSIZE(4096)       -
            FREESPACE(0 20)                 -
            KEYS(4 0) )                     -
       INDEX                                -
          (NAME(COM.MQM1.V8.BSDS01.INDEX)   -
           RECORDS(5 5)                     -
           CONTROLINTERVALSIZE(1024) )

            If you have 2 bootstraps....you would also allocate a V8.BSDS02

Step 2: Run the bootstrap conversion utility:

    //STEP3    EXEC PGM=CSQJUCNV,REGION=32M
  //*            PARM=('INQSG,++QSGNAME++,++DSGNAME++,++DB2SSID++') *QSG*
  //             PARM=('NOQSG')                                     *NOQSG*
  //SYSPRINT DD SYSOUT=*
  //SYSUT1   DD DSN=COM.MQM1.BSDS01,DISP=SHR        <== current BSDS01
  //*SYSUT2   DD DSN=COM.MQM1.BSDS02,DISP=SHR       <== current BSDS02 
  //SYSUT3   DD DSN=COM.MQM1.V8.BSDS01,DISP=OLD     <== new BSDS01
  //*SYSUT4   DD DSN=COM.MQM1.V8.BSDS02,DISP=OLD    <== new BSDS02


           In the above JCL, SYSUT2 and SYSUT 4 are commented out 
           since we are only doing a queue manager with a single BSDS. 
           If you are converting a queue manager running DUAL bootstraps, 
           then all 4 SYSUT# will be used.

Step 3: Rename the current bootstraps to a V71 name to move them out of the way:

    //STEP4     EXEC PGM=IDCAMS
  //SYSPRINT  DD   SYSOUT=*
  //SYSIN     DD   *
    ALTER 'COM.MQM1.BSDS01'       NEWNAME('COM.MQM1.V71.BSDS01')
    ALTER 'COM.MQM1.BSDS01.DATA'  NEWNAME('COM.MQM1.V71.BSDS01.DATA')
    ALTER 'COM.MQM1.BSDS01.INDEX' NEWNAME('COM.MQM1.V71.BSDS01.INDEX')
  //*

Step 4: Rename the new bootstraps (8 byte RBA) to the name the queue manager uses:

    //STEP4     EXEC PGM=IDCAMS
  //SYSPRINT  DD   SYSOUT=*
  //SYSIN     DD   *
    ALTER 'COM.MQM1.V8.BSDS01'       NEWNAME('COM.MQM1.BSDS01')
    ALTER 'COM.MQM1.V8.BSDS01.DATA'  NEWNAME('COM.MQM1.BSDS01.DATA')
    ALTER 'COM.MQM1.V8.BSDS01.INDEX' NEWNAME('COM.MQM1.BSDS01.INDEX')
  //*

Step 5: Start queue manager and check for new LOG RBA RANGE:

       CSQJ034I <MQM1 CSQJW007 END OF LOG RBA RANGE IS FFFFFFFFFFFFFFFF


That's it!!

Happy messaging.