IBM Support

Delay or AMQ9716 OCSP CRL revocation status error when starting MQ secure TLS SSL channels can cause performance issue, what is possible cause?

Troubleshooting


Problem

  • Delay or performance issue starting MQ SSL TLS channels.
  • Getting Delay or AMQ9716: Remote SSL certificate revocation status check failed when trying to start a MQ TLS SSL channel
  • Can occur on the both MQ server or also a MQ client application.
  • Also similar can occur with MQ AMS (Advanced Message Security) and MQ MFT/FTE (Managed File Transfer) with secure connections.
Following error may or may not be seen in error log:
AMQ9716: Remote SSL certificate revocation status check failed
Remote SSL certificate revocation status check failed for channel '???'.
EXPLANATION:WebSphere MQ failed to determine the revocation status of the remote SSL
certificate for one of the following reasons:
(a) The channel was unable to contact any of the CRL servers or OCSP responders for the certificate.
(b) None of the OCSP responders contacted knows the revocation status of the certificate.
(c) An OCSP response was received, but the digital signature of the response could not be verified.

Cause

Depending on your platform and actual certificates being used, part of IBM MQ's certificate validation is Online Certificate Status Protocol (OCSP) and Certificate revocation list (CRL) checking. This checking was not done before MQ v7.0.1.0. The information/settings here also applies to all distributed versions of MQ.
This checking occurs by default if your certificates or the Certificate Authority (CA) root/intermediate certificates have an AuthorityInfoAccess extension.
Most CA certificates have this extension.
If a location is included in the AuthorityInfoAccess extension, the SSL certificate validation logic will attempt to contact this location, to check if the certificate is valid.  

OCSP checking is done via http port 80.
We have seen many times, where the MQ server does not have access to http or the outside internet, and thus fails to be able to access the servers specified in the AuthorityInfoAccess extension. This can result in delays or failures trying to start TLS SSL channels.

Resolving The Problem

Options to resolve this:
1)
Ensure your MQ server has access to any CRL or OCSP servers. MQ allows you to configure a SSLHTTPProxyName, if needed, which can be used to configure access out to these servers, depending on your network configuration.  You may need to work with your network and or security team to ensure the MQ server host can access the remote OCSP/CRL locations.
If the certificate contains an AuthorityInfoAccess extension, ensure that the OCSP server named in the certificate extension is available and is correctly configured.  This is set in the certificate by the CA, you can check with your CA, if you believe these are incorrect.
If the certificate contains a CrlDistributionPoint extension, ensure that the CRL server named in the certificate extension is available and is correctly configured.  Again, you may need to work with your network, security team or CA provider.
If you have specified any CRL or OCSP servers to WebSphere MQ, check that those servers are available and accessible.
2)
You can disable the OCSP/CRL checking for your queue manager by adding an SSL stanza to your qm.ini, like the following: (for MQ client, add this to the mqclient.ini):
SSL:
  OCSPAuthentication=OPTIONAL
  OCSPCheckExtensions=NO
  CDPCheckExtensions=NO
With only OCSPAuthentication=OPTIONAL, MQ will still attempt to do the OCSP validation, if it eventually fails, the connection will still be allowed. To fully disable these checks, also set OCSPCheckExtensions=NO and CDPCheckExtensions=NO.
It was noted that just setting OCSPAuthentication=OPTIONAL alone may not be enough; with it set to OPTIONAL, if the certificate contains the OCSP info, the checking is still attempted, and this could "hang" or cause a performance issue at the network level, if it can not complete, thus test to also disable the Extension checks if the server can not access the OCSP/CRL responders.
Other certificate validation is still done, ie: validating the certificate chains, checking dates valid, etc.
 
see the following for details:
The same SSL Stanza also applies for a MQ client, it can be added into the mqclient.ini, if needed.
MQ client's also automatically attempt certificate OCSP/CRL checking if it is not disabled.
------------------
Similar can occur, if using MQ AMS (Advanced Message Security), if the client/host can not access the OCSP/CRL responders. See the following:
------------------
Similar occurred when updating certificate for MQ MFT/FTE.
In this case, the new certificate included AIA/OCSP information. AIA is the Authority Information Access oid in a certificate, it can contain information on where to go for OCSP (Online Certificate Status Protocol) checking.
MFT agent failed to connect, fteListAgent error 2397 and diagnostic message code was AMQ9771 in QMGR error logs saw:

AMQ9771 rrcE_SSL_JAVA_HANDSHAKE
Also received on qmgr:
AMQ9661: Bad SSL data from peer on channel
Customer's qmgr were NOT able to access OCSP responders via http.
Tested disabling the OCSP and extensions check worked around the issue.
 
Customer should work with their network team if this check is needed.
------------------
On Solaris, there is a relate fix to also check:
// IT17934: HANG OR SLOWNESS IN SSL/TLS CHANNELS DUE TO DELAYS IN CCIGSK_ENVIRONMENT_INIT
https://www.ibm.com/support/pages/apar/IT17934

Document Location

Worldwide

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"ARM Category":[{"code":"a8m0z00000008JwAAI","label":"Security->TLS (SSL)"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Version(s)","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
16 December 2020

UID

ibm16256630

Page Feedback