Configuring your system to use the Secure Sockets Layer (SSL)

If you want to use the Secure Sockets Layer (SSL) for channel security, there are a number of tasks we need to perform to set this up on your system. (See the WebSphere MQ Security book for more information about SSL.)

  1. Create a key ring in RACF to hold all the keys and certificates for your system, using the RACF RACDCERT command. For example:

    RACDCERT ID(QM1) ADDRING(QM1RING)

    The ID should be either the channel initiator address space user ID or the user ID you wish to own the keyring if it is to be a shared keyring.

  2. Create a digital certificate for each queue manager, using the RACF RACDCERT command.

    The label of the certificate must be of the form

    ibmWebSphereMQqmgr-name, so in this example it is ibmWebSphereMQQM1.

    For example:

    RACDCERT ID(QM1) GENCERT
    SUBJECTSDN(CN('username') O('IBM') OU('departmentname') C('England'))
    WITHLABEL('ibmWebSphereMQQM1')
    

  3. Connect the certificate in RACF to the key ring, using the RACF RACDCERT command. For example:

    RACDCERT CONNECT(ID(QM1) LABEL('ibmWebSphereMQQM1') RING(QM1RING))
    

    You also need to connect any relevant signer certificates (from a Certification Authority) to the key ring. That is, all Certification Authorities for this queue manager's SSL certificate and all Certification Authorities for all SSL certificates that this queue manager communicates with. For example:

    RACDCERT ID(userid) 
    CONNECT(CERTAUTH LABEL('My CA') RING(ring-name) USAGE(CERTAUTH))

  4. On each of your queue managers, use the WebSphere MQ ALTER QMGR command to specify the key repository that the queue manager needs to point to. For example, if the keyring is owned by the channel initiator address space:

    ALTER QMGR SSLKEYR(QM1RING)

    or if you are using a shared keyring:

    ALTER QMGR SSLKEYR(userid/QM1RING)

    where userid is the user ID that owns the shared keyring.

  5. Certificate Revocation Lists (CRLs) allow the Certification Authorities to revoke certificates that can no longer be trusted. CRLs are stored in LDAP servers. To access this list on the LDAP server, you first need to create an AUTHINFO object of AUTHTYPE CRLLDAP, using the WebSphere MQ DEFINE AUTHINFO command. For example:

    DEFINE AUTHINFO(LDAP1)
    AUTHTYPE(CRLLDAP) 
    CONNAME(ldap.server(389))  
    LDAPUSER('')  
    LDAPPWD('')

    In this example, the certificate revocation list is stored in a public area of the LDAP server, so the LDAPUSER and LDAPPWD fields are not neccessary.

    Next, put your AUTHINFO object into a namelist, using the WebSphere MQ DEFINE NAMELIST command. For example:

    DEFINE NAMELIST(LDAPNL) NAMES(LDAP1)
    Finally, associate the namelist with each queue manager, using the WebSphere MQ ALTER QMGR command. For example:

    ALTER QMGR SSLCRLNL(LDAPNL)

  6. Set up your queue manager to run SSL calls, using the WebSphere MQ ALTER QMGR command. This defines server subtasks that handle SSL calls only, which leaves the normal dispatchers to continue processing as normal without being impacted by any SSL calls. You must have at least two of these subtasks. For example:

    ALTER QMGR SSLTASKS(8)

    This change only takes effect when the channel initiator is restarted.

  7. Specify the cipher specification to be used for each channel, using the WebSphere MQ DEFINE CHANNEL or ALTER CHANNEL command. For example:

    ALTER CHANNEL(LDAPCHL)
    CHLTYPE(SDR)
    SSLCIPH(RC4_MD5_US)
    
    Both ends of the channel must specify the same cipher specification.