Working with Online Certificate Status Protocol (OCSP)

IBM® MQ determines which Online Certificate Status Protocol (OCSP) responder to use, and handles the response received. You might have to take steps to make the OCSP responder accessible.

An authentication information object contains authentication information that is used when checking whether a TLS certificate is revoked or not.
Note: This information applies only to IBM MQ on UNIX and Windows systems. The following table shows the IBM MQ TLS authentication information support for different platforms:
Table 1. Authentication information support for different platforms
Platform Support
[Windows]IBM MQ on Windows systems [Windows]IBM MQ TLS supports checks for revoked certificates using OCSP, or using CRLs and ARLs on LDAP servers, with OCSP as the preferred method. IBM MQ classes for Java cannot use the OCSP information in a client channel definition table file. However, you can configure OCSP as described in Revoked certificates and OCSP in the product documentation.
[UNIX]IBM MQ on UNIX systems [UNIX]IBM MQ TLS supports checks for revoked certificates using OCSP, or using CRLs and ARLs on LDAP servers, with OCSP as the preferred method. IBM MQ classes for Java cannot use the OCSP information in a client channel definition table file. However, you can configure OCSP as described in Revoked certificates and OCSP in the IBM MQ online product documentation.
[z/OS]IBM MQ on z/OS® systems [z/OS]IBM MQ TLS supports checks for revoked certificates using CRLs and ARLs on LDAP servers only. IBM MQ on z/OS systems cannot use OCSP.
[IBM i]IBM MQ on IBM i systems [IBM i]IBM MQ TLS supports checks for revoked certificates using CRLs and ARLs on LDAP servers only. IBM MQ on IBM i systems cannot use OCSP.
To check the revocation status of a digital certificate using OCSP, IBM MQ determines which OCSP responder to contact in one of two ways:
  • Using the AuthorityInfoAccess (AIA) certificate extension in the certificate to be checked.
  • Using a URL specified in an authentication information object or specified by a client application.

A URL specified in an authentication information object or by a client application takes priority over a URL in an AIA certificate extension.

The URL of the OCSP responder might lie behind a firewall; if so, reconfigure the firewall so the OCSP responder can be accessed or set up an OCSP proxy server. Specify the name of the proxy server by using the SSLHTTPProxyName variable in the SSL stanza. On client systems, you can also specify the name of the proxy server by using the environment variable MQSSLPROXY.

If you are not concerned whether TLS certificates are revoked, perhaps because you are running in a test environment, you can set OCSPCheckExtensions to NO in the SSL stanza. If you set this variable, any AIA certificate extension is ignored. This solution is unlikely to be acceptable in a production environment, where you probably do not want to allow access from users presenting revoked certificates.

The call to access the OCSP responder can return one of the following three outcomes:
Good
The certificate is valid.
Revoked
The certificate is revoked.
Unknown
This outcome can arise for one of three reasons:
  • IBM MQ cannot access the OCSP responder.
  • The OCSP responder has sent a response, but IBM MQ cannot verify the digital signature of the response.
  • The OCSP responder has sent a response that indicates that it has no revocation data for the certificate.

By default, IBM MQ rejects a connection if it receives an OCSP response of Unknown, and issues an error message. You can change this behavior by setting the OCSPAuthentication attribute. This is held in the SSL stanza of the qm.ini file for UNIX systems, the WebSphere® registry, or the SSL stanza of the client configuration file. It can be set using the IBM MQ Explorer on applicable platforms.

OCSP outcome Unknown

If IBM MQ receives an OCSP outcome of Unknown, its behavior depends on the setting of the OCSPAuthentication attribute. For queue managers, this attribute is held in the SSL stanza of the qm.ini file for UNIX systems, or the Windows registry, and it can be set using the IBM MQ Explorer. For clients, it is held in the SSL stanza of the client configuration file.

If an outcome of Unknown is received and OCSPAuthentication is set to REQUIRED (the default value), IBM MQ rejects the connection and issues an error message of type AMQ9716. If queue manager SSL event messages are enabled, an SSL event message of type MQRC_CHANNEL_SSL_ERROR with ReasonQualifier set to MQRQ_SSL_HANDSHAKE_ERROR is generated.

If an outcome of Unknown is received and OCSPAuthentication is set to OPTIONAL, IBM MQ allows the SSL channel to start and no warnings or SSL event messages are generated.

If an outcome of Unknown is received and OCSPAuthentication is set to WARN, the SSL channel starts but IBM MQ issues a warning message of type AMQ9717 in the error log. If queue manager SSL event messages are enabled, an SSL event message of type MQRC_CHANNEL_SSL_WARNING with ReasonQualifier set to MQRQ_SSL_UNKNOWN_REVOCATION is generated.

Digital signing of OCSP responses

An OCSP responder can sign its responses in any of three ways. Your responder will inform you which method is used.
  • The OCSP response can be digitally signed using the same CA certificate that issued the certificate that you are checking. In this case, you do not need to set up any additional certificate; the steps you have already taken to establish SSL connectivity are sufficient to verify the OCSP response.
  • The OCSP response can be digitally signed using another certificate signed by the same (CA) that issued the certificate you are checking. The signing certificate is flowed together with the OCSP response in this case. The certificate flowed from the OCSP responder must have an Extended Key Usage Extension set to id-kp-OCSPSigning so that it can be trusted for this purpose. Because the OCSP response is flowed with the certificate which signed it (and that certificate is signed by a CA which is already trusted for SSL connectivity) then no additional certificate setup is required.
  • The OCSP response can be digitally signed using another certificate which is not directly related to the certificate you are checking. In this case, the OCSP Response is signed by a certificate issued by the OCSP responder itself. You must add a copy of the OCSP responder certificate to the key database of the client or queue manager which performs the OCSP checking. See Adding a CA certificate (or the CA part of a self-signed certificate) into a key repository in the IBM MQ online product documentation. When a CA certificate is added, by default it is added as a trusted root, which is the required setting in this context. If this certificate is not added, IBM MQ cannot verify the digital signature on the OCSP response and the OCSP check results in an Unknown outcome, which might cause IBM MQ to close the channel, depending on the value of OCSPAuthentication.