Location of an OCSP responder, and of LDAP servers that hold CRLs

On an IBM MQ MQI client system, we can specify the location of an OCSP responder, and of Lightweight Directory Access Protocol (LDAP) servers that hold certificate revocation lists (CRLs).

We can specify these locations in three ways, listed here in order of decreasing precedence. (For IBM i, see Accessing CRLs and ARLs on IBM i.)


When an IBM MQ MQI client application issues an MQCONNX call

We can specify an OCSP responder or an LDAP server holding CRLs on an MQCONNX call.

On an MQCONNX call, the connect options structure, MQCNO, can reference an SSL configuration options structure, MQSCO. In turn, the MQSCO structure can reference one or more authentication information record structures, MQAIR. Each MQAIR structure contains all the information an IBM MQ MQI client requires to access an OCSP responder or an LDAP server holding CRLs. For example, one of the fields in an MQAIR structure is the URL at which a responder can be contacted. For more information about the MQAIR structure, see MQAIR - Authentication information record.


Use a client channel definition table (ccdt) to access an OCSP responder or LDAP servers

So that an IBM MQ MQI client can access an OCSP responder or LDAP servers that hold CRLs, include the attributes of one or more authentication information objects in a client channel definition table.

On a server queue manager, we can define one or more authentication information objects. The attributes of an authentication object contain all the information that is required to access an OCSP responder (on platforms where OCSP is supported) or an LDAP server that holds CRLs. One of the attributes specifies the OCSP responder URL, another specifies the host address, or IP address of a system on which an LDAP server runs.

An authentication information object with AUTHTYPE(OCSP) does not apply for use on IBM i or z/OS® queue managers, but it can be specified on those platforms to be copied to the client channel definition table (CCDT) for client use.

To enable an IBM MQ MQI client to access an OCSP responder or LDAP servers that hold CRLs, the attributes of one or more authentication information objects can be included in a client channel definition table. We can include such attributes in one of the following ways:

    On server platforms AIX , HP-UX, Linux , IBM i, Solaris, and Windows

    We can define a namelist that contains the names of one or more authentication information objects. We can then set the queue manager attribute, SSLCRLNameList, to the name of this namelist.

    If you are using CRLs, more than one LDAP server can be configured to provide higher availability. The intention is that each LDAP server holds the same CRLs. If one LDAP server is unavailable when it is required, an IBM MQ MQI client can attempt to access another.

    The attributes of the authentication information objects identified by the namelist are referred to collectively here as the certificate revocation location. When you set the queue manager attribute, SSLCRLNameList, to the name of the namelist, the certificate revocation location is copied into the client channel definition table associated with the queue manager. If the CCDT can be accessed from a client system as a shared file, or if the CCDT is then copied to a client system, the IBM MQ MQI client on that system can use the certificate revocation location in the CCDT to access an OCSP responder or LDAP servers that hold CRLs.

    If the certificate revocation location of the queue manager is changed later, the change is reflected in the CCDT associated with the queue manager. If the queue manager attribute, SSLCRLNameList, is set to blank, the certificate revocation location is removed from the CCDT. These changes are not reflected in any copy of the table on a client system.

    If you require the certificate revocation location at the client and server ends of an MQI channel to be different, and the server queue manager is the one that is used to create the certificate revocation location, we can do it as follows:
    1. On the server queue manager, create the certificate revocation location for use on the client system.
    2. Copy the CCDT containing the certificate revocation location to the client system.
    3. On the server queue manager, change the certificate revocation location to what is required at the server end of the MQI channel.
    4. On the client machine, we can use the runmqsc command with the -n parameter.

    On client platforms AIX, HP-UX, Linux, IBM i, Solaris, and Windows

    We can build a CCDT on the client machine by using the runmqsc command with the -n parameter and DEFINE AUTHINFO objects in the CCDT file. The order that the objects are defined in is the order in which they are used in the file. Any name that you might use in a DEFINE AUTHINFO object is not retained in the file. Only positional numbers are used when you DISPLAY the AUTHINFO objects in a CCDT file.

    Note: If you specify the -n parameter, you must not specify any other parameter.


Use Active Directory on Windows

On Windows systems, we can use the setmqcrl control command to publish the current CRL information in Active Directory.

Command setmqcrl does not publish OCSP information.

For information about this command and its syntax, see setmqcrl.