Work with Online Certificate Status Protocol (OCSP)

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

• Use the AuthorityInfoAccess (AIA) certificate extension in the certificate to be checked.
• Use 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, we can also specify the name of the proxy server by using the environment variable MQSSLPROXY.

If we are not concerned whether TLS certificates are revoked, perhaps because we are running in a test environment, we 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.

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. We 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

• The OCSP response can be digitally signed using the same CA certificate that issued the certificate that we 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 we 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 we are checking. In this case, the OCSP Response is signed by a certificate issued by the OCSP responder itself. We 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. 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.

Parent topic: Authentication information

Related concepts

• Namelists

Related tasks

• Create and configure queue managers and objects
• Delete queue managers and objects
• Configure TLS on queue managers

Related reference

• Work with revoked certificates
• Authentication information properties