LDAP and CRLs

MQIPT supports use of a Lightweight Directory Access Protocol (LDAP) server to perform Certificate Revocation List (CRL) authentication on a digital certificate. LDAP support has been implemented in a similar way to that in IBM MQ, as the same LDAP server can be used for both IBM MQ and MQIPT.

During the SSL/TLS handshake, the communicating partners authenticate each other with digital certificates. Authentication can include a check that the certificate received can still be trusted. Certification Authorities (CAs) revoke certificates for various reasons, including the following:

• The owner has moved to a different organization.
• The private key is no longer secret.

CAs publish revoked personal certificates in a Certificate Revocation List (CRL). CA certificates that have been revoked are published in an Authority Revocation List (ARL). Note that subsequent references to CRLs also apply to ARLs.

For further information about the use of LDAP servers with IBM MQ and about the management of CRLs and ARLs, see Work with Certificate Revocation Lists and Authority Revocation Lists.

MQIPT can support up to two LDAP servers on each route. The first LDAP server is treated as the main server with the second LDAP server kept as a backup. The second server is only used if the main server cannot be reached. The backup server should be a mirror image of the main server.

Access to information stored on an LDAP server can be protected with a user ID and password by using the LDAP user ID and password properties. LDAP server passwords can be encrypted in the MQIPT configuration from Version 9.1.5. For more information on encrypting passwords to be used by MQIPT, see Encrypting stored passwords.

When MQIPT loads a PKCS #12 token from a key ring file, any CA certificates are checked for CRL validity. If the CA certificate has an attached CRL, it is checked to see if it has expired and, if so, a newer CRL is retrieved from the LDAP server. Any CRL retrieved is loaded into the current token and attached to its CA certificate.

If there are no entries that match the given CA when a query is sent to the main LDAP server, it is assumed there are no CRLs for that CA and the backup server is not used. However, if the main LDAP server cannot be reached or does not return within a given time frame, the backup server is used. Any errors from the backup server cause the client connection to be ended. This action can be overridden by setting the LDAPIgnoreErrors property to true.

Any CRLs retrieved by MQIPT are kept in a cache and shared by all connections on that route. If a cached CRL has expired, the CRL is removed from the cache and a new one is retrieved from the LDAP server. If a new CRL is not available the connection is still refused.

A CRL retrieved from the LDAP server is also checked for expiry and a warning message is displayed (MQCPW001). The expired CRL is still loaded into the system and any connection requests referencing that CRL are refused. We should replace the expired CRL in the LDAP server with a current one.

The LDAPCacheTimeout property can be used to control how often the CRL cache is cleared. The default value is 1 day. Setting this value to 0 means the cache entries are not cleared until the route is restarted.

An expired CRL can be stored in a key ring file or on an LDAP server. If a new CRL has not been issued, further connection requests are refused. We can ignore expired CRLs by enabling the IgnoreExpiredCRLs property.