Practical mastering IBM MQ basics

*This series may be revised based on the latest mqpgf/mqpcf. Please always download and use the latest version.

IBM MQ supports two ways to verify a revoked digital certificate: OCSP(Online Certificate Status Protocol), CRL(Certificate Revocation Lists) and ARL(Authority Revocation Lists) on LDAP (Lightweight Directory Access Protocol) servers.

*Here, the uses of CRL and ARL are as follows.

This time, we will use OCSP to examine the behavior when the server certificate of the opposite channel is revoked. In the verification tests so far, we have built an intranet CA on each server of Windows, Linux, and HPE NonStop, so start the OCSP responder on the CA on each machine. The openssl command can be started as an OCSP responder, so use that function.
The following methods are roughly supported for referencing the OCSP responder.

Here, on the server side, the "authentication information object", which is more flexible than the "AIA certificate extension", is used, and on the client connection, the "OCSP Responder URL of the MQAIR structure" is used for verification.
After this, it is assumed that the procedure for using server-to-server connection and client connection using SSL/TLS on previously sections has been executed. So if you have not done so, please refer to the previous chapters. It doesn't matter if you use elliptic curves or not.

Prerequisites and restrictions for OCSP configuration

We will summarize the prerequisites and restrictions for using OCSP with IBM MQ. If you already have an understanding of OCSP, it may include something you already know.

First configure the server-to-server connection. In the verification environment created so far, we built a CA on each server and issued a server certificate. Therefore, start the OCSP responder on the CA of each server and connect from the queue manager on the opposite side.
The procedure is the same regardless of whether the server used for verification is Windows / Linux / HPE NonStop, so select it arbitrarily.

Launch and verify OCSP responder using openssl

First, check the basic operation of OCSP Reponder without using IBM MQ.

Launch OCSP Responder

The method for starting the OCSP responder is the same for Windows, Linux, and HPE NonStop, and the ocsp utility of the openssl command is used. Move to the CA directory created by each and execute the following command. If you do not specify "-ignore_err", an error may occur at startup and you may not be able to start. It also has the effect of avoiding an error termination when a port scan is performed. Since openssl.cnf is not used, it is not necessary to set the OPENSSL_CONF environment variable, but if you are concerned about WARNING, refer to openssl.cnf used when creating the CA. You will be asked for the pass phrase of the CA's private key, and if you enter it, it will be waiting for a connection from the OCSP client. The following is an example of starting with HPE NonStop, but the same command line is used for Windows and Linux.
*Openssl installed by MQ8 for HPE NonStop does not support OCSP responder mode at least at the time of this writing, and even if you try to start it, it will fail. HUse another separately installed openssl on HPE NonStop. OCSP client mode can also be used with the openssl command bundled with MQ8 without any problems.

cd .../openssl/nsca >openssl ocsp -ignore_err -index index.txt -CA cacert.pem -rsigner cacert.pem -rkey private/cakey.pem -port 2560 Enter pass phrase for private/cakey.pem: nsca ocsp: waiting for OCSP client connections...

*Option descriptions
ocsp: Runs the Online Certificate Status Protocol utility.
-index indexfile: indexfile is a ca-formatted text index file that contains certificate revocation information.
*If the "index" option is specified, the ocsp utility will be in responder mode. Otherwise it works in client mode.
-CA file: Specify the CA certificate.
-rsigner file: Specifies the certificate to sign the OCSP response.
-rkey file: Specifies the private key to sign the OCSP response.
-port portnum: Specifies the port on which to listen for OCSP requests.

Checking the connection to the OCSP responder

Verify that the server certificate connection / verification by OCSP is successful. The openssl ocsp command is in responder mode if the -index option is specified, or in client mode if it is not specified. You can use this client mode to verify operation by connecting to a started OCSP responder. If you can obtain the certificate of the server on the other side to be verified, transfer it by FTP etc. and specify it in the command.
Below is an example of validating a NonStop server certificate from Linux. Specify and verify the CA certificate (cacert_ns.pem) and server certificate (PL81NA.pem) on the NonStop side from the Linux side.
Depending on the version of openssl, the warning message "WARNING: Status times invalid." may be output, but it seems to be due to a bug in the openssl command, so you can ignore it.

$ openssl ocsp -issuer cacert_ns.pem -cert PL81NA.pem -url http://<ipaddr or hostname>:<port>/ -CAfile cacert_ns.pem
Response verify OK
PL81NA.pem: good
This Update: Sep 8 08:17:42 2021 GMT

$

*Option descriptions
ocsp: Runs the Online Certificate Status Protocol utility.
-issuer filename: Specify the latest issuer's certificate. The specified certificate must be in PEM format. This option allows multiple specifications.
-cert filename: Specify the file name of the certificate to be verified.
-url responder_url: Specify the responder URL. You can specify HTTP or HTTPS(SSL/TLS) URLs.
-CAfile file, -CApath pathname: Specify the CA certificate for file or pathname. These are used for signature validation in OCSP responses.

*-CAfile / -CApath is specified when the certificate chain contains an intermediate CA certificate. Since the CA is only the root certificate this time in the certificate chain, you can omit the -CAfile / -CApath specification, but depending on the version of openssl, if you do not specify the root certificate, you may get "Response Verify Failure".

If you only want to check whether the URL to connect to the OCSP responder is correct, you can specify a dummy certificate that is not issued by the CA to connect to in the command. If a certificate that is not in the index.txt of the CA on the OCSP responder side is specified, "Response verify OK" is output, and then "xxxx.pem: unknown"is displayed.

$ openssl ocsp -issuer cacert_ns.pem -cert PL921WCA.pem -url http://<ipaddr or hostname>:<port>/
Response verify OK
PL921WCA.pem: unknown
This Update: Sep 8 07:42:15 2021 GMT

$

Revoke the certificate at CA

Next, check if revocation is detected as expected.
Revoking is done with the openssl command. When revoked, the first character of the list of certificate information issued by the CA, which is recorded in the index.txt of the CA, is changed from "V" to "R".
In the following, the certificate is revoked on the Linux server and the certificate is sent from another server, but the procedure is the same for each platform.

$ cd .../openssl/lnxca
$ cat index.txt
V 310802080523Z 01 unknown /C=US/ST=New York/O=Pulsar Integration PL91LA Inc./CN=www.ny.pulsarintegration.PL92L.com
$
$ openssl ca -config openssl.cnf -cert cacert.pem -keyfile private/cakey.pem -revoke /var/mqm/qmgrs/PL91L/ssl/PL91LA.pem
Using configuration from openssl.cnf
Enter pass phrase for private/cakey.pem: lnxca
Revoking Certificate 01.
Data Base Updated
$
$ cat index.txt
R 310802080523Z 210913024444Z 01 unknown /C=US/ST=New York/O=Pulsar Integration PL91LA Inc./CN=www.ny.pulsarintegration.PL92L.com

*Option descriptions
ca: Performs basic CA functions and issues X.509 certificates and certificate revocation lists.
-config filename: Specify the openssl configuration file.
Priority over the OPENSSL_CONF environment variable.
-cert filename: Specify the file name where the CA certificate is stored.
-keyfile filename: Specify the file name where the CA private key is stored.
-revoke filename: Specify the filename that contains the certificate to revoke.

Openssl responder mode reads the index.txt file only at startup, so you must manually restart the OCSP responder after revoking the certificate. Don't forget to run it.
*If the OCSP responder is started immediately after it is stopped, an error may occur. In that case, wait for a certain period of time before starting.

...
ocsp: waiting for OCSP client connections...

*Interrupt by CTRL+C
*Restart after revoking
$ openssl ocsp -ignore_err -index index.txt -CA cacert.pem -rsigner cacert.pem -rkey private/cakey.pem -port 2560
...
ocsp: waiting for OCSP client connections...

...
ocsp: waiting for OCSP client connections...

*Interrupt by CTRL+C
$ cat index.txt.old
V 310802080523Z 01 unknown /C=US/ST=New York/O=Pulsar Integration PL91LA Inc./CN=www.ny.pulsarintegration.PL92L.com
$ cp -p index.txt.old index.txt
$ openssl ocsp -ignore_err -index index.txt -CA cacert.pem -rsigner cacert.pem -rkey private/cakey.pem -port 2560
...
ocsp: waiting for OCSP client connections...

Confirmation of certificate verification by OCSP

Issue a command similar to checking the connection. Confirm that "revoked" is displayed.

openssl ocsp -issuer cacert_lnx.pem -cert PL91LA.pem -url http://<ipaddr or hostname>:<port>/
Response verify OK
PL91LA.pem: revoked
This Update: Sep 13 02:49:27 2021 GMT
Revocation Time: Sep 13 02:44:44 2021 GMT

Here is a summary of the status displayed by the OCSP client.

Using OCSP for MQ server-to-server connections

It is assumed that a server-to-server connection channel using TLS has already been created in both directions and is ready for communication. In that state, create AUTHINFO that define the connection to the OCSP responder so that the queue manager can see it.

Configuring OCSP responder references for server-to-server connections

The following is a definition example. Define a reference to the opposing OCSP responder in the OCSPURL property of AUTHINFO. Both sides that verify the connection may perform certificate verification by OCSP with each other, or only one side. It is the same except for the setting value of OCSPURL. Of course, you can name each object freely.

*Definition of authentication information object. In the OCSP URL, set a reference to the OCSP responder started by the CA that issued the server certificate of the opposite server. You cannot specify the source address (LOCLADDR).
mqpcf mqsc -qm <qmgr name> -s "def authinfo(<authinfo name>) authtype(OCSP) OCSPURL('http://<ip addr or hostname>:2560') replace"

*Creating a name list of authentication information
mqpcf mqsc -qm <qmgr name> -s 'def namelist(<namelist name>) names(<authinfo name>) replace'

*Set the created name list to SSLCRLNL(certificate revocation list name list) of the queue manager.
mqpcf mqsc -qm <qmgr name> -s 'alter qmgr SSLCRLNL(<namelist name>)'

*Refreshing SSL / TLS setting information.
If this is done while the channel is connected, it may take some time to receive the refresh command execution result from the command server. In that case the response from the command server is delayed and after the default 10 second response wait time you will see reason code 2033(MQRC_NO_MSG_AVAILABLE).

MQExecute : Message Get Fail(no msg available).CompCode=[2], ReasonCode=[2033]

In that case, specify the waiting time until the response is received with "-w".
mqpcf mqsc -qm <qmgr name> -wi 60 -s 'refresh security type(SSL)'

*Option descriptions
mqsc: Execute MQSC command string or read MQSC script file
-s: Specify the MQSC command string.
-wi: Wait time to receive a response from the command server.

Make sure the channel starts successfully. Below is an example of a connection between a Windows machine and a NonStop machine.

$ mqpcf chs -qm PL81N -c PL* SECPROT SSLCERTI SSLCIPH SSLPEER
1: CHANNEL(PL92W.PL81N) CHLTYPE(RCVR) CONNAME(xxx.xxx.xxx.xxx) CHLINSTYPE(CURRENT) RQMNAME(PL92W) SECPROT(TLSV12) SSLCERTI(E=support@pulsarintegration.com,CN=www.pulsarintegration.com,O=Pulsar Integration Inc.,ST=Chiba,C=JP) SSLCIPH(TLS_RSA_WITH_AES_256_CBC_SHA256) SSLPEER(SERIALNUMBER=01,CN=www.pulsarintegration.PL92W.com,O=Pulsar Integration PL92WA Inc.,ST=Chiba,C=JP) STATUS(RUNNING) STOPREQ(NO) SUBSTATE(RECEIVE)
2: CHANNEL(PL81N.PL92W) CHLTYPE(SDR) CONNAME(xxx.xxx.xxx.xxx(xxxx)) CHLINSTYPE(CURRENT) RQMNAME(PL92W) SECPROT(TLSV12) SSLCERTI(E=support@pulsarintegration.com,CN=www.pulsarintegration.com,O=Pulsar Integration Inc.,ST=Chiba,C=JP) SSLCIPH(TLS_RSA_WITH_AES_256_CBC_SHA256) SSLPEER(SERIALNUMBER=01,CN=www.pulsarintegration.PL92W.com,O=Pulsar Integration PL92WA Inc.,ST=Chiba,C=JP) STATUS(RUNNING) STOPREQ(NO) SUBSTATE(MQGET) XMITQ(PL92W)

Behavior when unable to connect to OCSP responder

Stop the OCSP responder on one side. Since TLS is bidirectional authentication, both send and receive channels should not be able to connect with TLS.

As an example, stop the OCSP responder on the Windows side. The NonStop server-side channel will not be able to check the Windows-side server certificate.

\openssl\winca>openssl ocsp -ignore_err -index index.txt -CA cacert.pem -rsigner cacert.pem -rkey private/cakey.pem -port 2560
Enter pass phrase for private/cakey.pem:
ocsp: waiting for OCSP client connections...
^C *Interrupt by CTRL+C
\openssl\winca>

Restart the channel from the sender(SDR) channel on both machines to check the status.
First, Restart the sender(SDR) channel on the NonStop side.

*Restarting the channel from the sender side(SDR) on the NonStop. $ mqpcf stp -qm PL81N -c PL81N.PL92W Channel Stop Success. Channel Name : PL81N.PL92W Connection Name : Queue Manager : $ mqpcf sta -qm PL81N -c PL81N.PL92W Channel Start Success. Channel Name : PL81N.PL92W *The channel status will change to RETRYING after BINDING continues for a while. $ mqpcf chs -qm PL81N -c PL81N.PL92W STATUS 1: CHANNEL(PL81N.PL92W) CHLTYPE(SDR) CONNAME(xxx.xxx.xxx.xxx(xxxx)) CHLINSTYPE(CURRENT) RQMNAME() STATUS(BINDING) STOPREQ(NO) SUBSTATE(OTHER) XMITQ(PL92W) ... $ mqpcf chs -qm PL81N -c PL81N.PL92W STATUS 1: CHANNEL(PL81N.PL92W) CHLTYPE(SDR) CONNAME(xxx.xxx.xxx.xxx(xxxx)) CHLINSTYPE(CURRENT) RQMNAME() STATUS(RETRYING) STOPREQ(NO) SUBSTATE(OTHER) XMITQ(PL92W)

Check the output contents to both error logs.

*AMQ9665E is output to the Windows (RCVR) side, and it is reported that the TLS connection has been closed by the remote side. ----- amqcrhna.c : 789 -------------------------------------------------------- AMQ9665E: SSL connection closed by remote end of channel '????' ----- amqccisa.c : 8789 ------------------------------------------------------- *AMQ9716 was output to the NonStop (SDR) side, and the revoking status could not be confirmed that is displayed as the reason why the channel could not be started. ------------------------------------------------------------------------------- AMQ9716: Remote SSL certificate revocation status check failed for channel 'PL81N.PL92W'. .... The details of the certificate in question are '/C=JP/ST=Chiba/O=Pulsar Integration PL92WA Inc./CN=www.pulsarintegration.PL92W.com'. .... IBM MQ does not allow the channel to start unless the certificate revocation status can be determined. .... ----- amqcciso.c : 3968 -------------------------------------------------------

Then restart the sender(SDR) channel on the opposite Windows side.

*Restart the channel of the sender(SDR) on the Windows side, >mqpcf stp -qm PL92W -c PL92W.PL81N Channel Stop Success. Channel Name : PL92W.PL81N Connection Name : Queue Manager : >mqpcf sta -qm PL92W -c PL92W.PL81N Channel Start Success. Channel Name : PL92W.PL81N *The channel status will change to RETRYING after BINDING and SUBSTATE (SSLHANDSHK) continue for a while. >mqpcf chs -qm PL92W -c PL92W.PL81N STATUS 1: CHANNEL(PL92W.PL81N) CHLTYPE(SDR) CONNAME(xxx.xxx.xxx.xxx(xxxx1)) CHLINSTYPE(CURRENT) RQMNAME() STATUS(BINDING) STOPREQ(NO) SUBSTATE(SSLHANDSHK) XMITQ(PL81N) >mqpcf chs -qm PL92W -c PL92W.PL81N STATUS 1: CHANNEL(PL92W.PL81N) CHLTYPE(SDR) CONNAME(xxx.xxx.xxx.xxx(xxxx)) CHLINSTYPE(CURRENT) RQMNAME() STATUS(RETRYING) STOPREQ(NO) SUBSTATE(OTHER) XMITQ(PL81N)

Check the output contents to both error logs.

*AMQ9665E is output to the Windows (RCVR) side, and it is reported that the TLS connection has been closed by the remote side. ----- amqcrhna.c : 789 -------------------------------------------------------- AMQ9665E: SSL connection closed by remote end of channel 'PL92W.PL81N' ----- amqccisa.c : 8789 ------------------------------------------------------- *AMQ9716 is output to the NonStop(RCVR) side, and the revoking status could not be confirmed that is displayed as the reason why the channel could not be started. ----- amqrmrsa.c : 926 -------------------------------------------------------- AMQ9716: Remote SSL certificate revocation status check failed for channel .... The details of the certificate in question are '/C=JP/ST=Chiba/O=Pulsar Integration PL92WA Inc./CN=www.pulsarintegration.PL92W.com'. .... IBM MQ does not allow the channel to start unless the certificate revocation status can be determined. .... ----- amqcciso.c : 3968 -------------------------------------------------------

You can see that the same error message is output on each machine regardless of the channel transmission / reception direction.

Changes in behavior when the certificate cannot be verified(Unknown)

The reason why the certificate cannot be verified(Unknown) has already been introduced, including the case where the OCSP responder cannot be connected, but there are the following three cases.

In IBM MQ, the behavior when the certificate has a validation status of Unknown can be changed by setting the OCSPAuthentication parameter in the SSL stanza of the qm.ini file. REQUIRED (default) / OPTIONAL / WARN can be set, and the operation in each case is changed as follows.

Behavior when the query result to the OCSP responder is "Revoked"

As an example, revoke the server certificate on the NonStop side. Since it is a two-way authentication, both the send and receive channels should not be able to connect with TLS.

$ cd .../openssl/nsca $ openssl ca -config openssl.cnf -cert cacert.pem -keyfile private/cakey.pem -revoke .../var/ mqm/qmgrs/PL81N/ssl/PL81NA.pem Using configuration from openssl.cnf Enter pass phrase for private/cakey.pem: Revoking Certificate 01. Data Base Updated $ $ cat index.txt R 310802082027Z 210929080911Z 01 unknown /C=AU/ST=Sydney/O=Pulsar Integration PL81NA Inc./CN=www.sd.pulsarintegration.PL81N.com V 310824073603Z 02 unknown /C=AU/ST=Sydney/O=Pulsar Integration PL81NA Inc./CN=www.sd.pulsarintegration.PL81Nec.com

Don't forget to restart the OCSP responder.

$ openssl ocsp -ignore_err -index index.txt -CA cacert.pem -rsigner cacert.pem -rkey private/ cakey.pem -port 2560 Enter pass phrase for private/cakey.pem: Waiting for OCSP client connections... ^C *Interrupt by CTRL+C $ $ openssl ocsp -ignore_err -index index.txt -CA cacert.pem -rsigner cacert.pem -rkey private/ cakey.pem -port 2560 Enter pass phrase for private/cakey.pem: nsca Waiting for OCSP client connections...

Restart the channel from the sender(SDR) channel on both machines to check the status.
First, restart the sender(SDR) channel on the NonStop side.

*Restart the the sender side(SDR) channel on the NonStop. $ mqpcf stp -qm PL81N -c PL81N.PL92W Channel Stop Success. Channel Name : PL81N.PL92W Connection Name : Queue Manager : $ mqpcf sta -qm PL81N -c PL81N.PL92W Channel Start Success. Channel Name : PL81N.PL92W *The channel status will be "RETRYING". $ mqpcf chs -qm PL81N -c PL81N.PL92W STATUS 1: CHANNEL(PL81N.PL92W) CHLTYPE(SDR) CONNAME(xxx.xxx.xxx.xxx(xxxx)) CHLINSTYPE(CURRENT) RQMNAME() STATUS(RETRYING) STOPREQ(NO) SUBSTATE(OTHER) XMITQ(PL92W)

Check the output contents to both error logs.

*AMQ9633E is output to the Windows(RCVR) side, and shows that the certificate was invalid as the reason why the channel could not be started. ----- amqcrhna.c : 789 -------------------------------------------------------- AMQ9633E: Bad SSL certificate for channel '????' .... (e) an OCSP responder has indicated that it is revoked .... The details of the certificate which could not be validated are '[Class=]GSKVALMethod::X509[Issuer=]EMAIL=support@sd.pulsarintegration.com, CN=www.sd.pulsarintegration.com,O=Pulsar Integration SD Inc.,ST=Sydney,C=AU[#=]01[Subject=]CN=www.sd.pulsarintegration.PL81N.com,O=Pulsar Integration PL81NA Inc.,ST=Sydney,C=AU' The certificate validation error was 575032. .... ----- amqccisa.c : 8789 ------------------------------------------------------- *AMQ9633 is also output to the NonStop (SDR) side, and the reason why the channel could not be started is that the certificate was invalid. ------------------------------------------------------------------------------- AMQ9633: Bad SSL certificate for channel 'PL81N.PL92W'. .... (e) an OCSP responder has indicated that it is revoked .... The details of the certificate which could not be validated are 'sslv3 alert bad certificate'. The certificate validation error was 1042. .... ----- amqcciso.c : 9785 -------------------------------------------------------

Then restart the sender(SDR) channel on the opposite Windows side.

*Restart the channel of the sender(SDR) on the Windows side, >mqpcf stp -qm PL92W -c PL92W.PL81N Channel Stop Success. Channel Name : PL92W.PL81N Connection Name : Queue Manager : >mqpcf sta -qm PL92W -c PL92W.PL81N Channel Start Success. Channel Name : PL92W.PL81N *The channel status will be "RETRYING". >mqpcf chs -qm PL92W -c PL92W.PL81N STATUS 1: CHANNEL(PL92W.PL81N) CHLTYPE(SDR) CONNAME(xxx.xxx.xxx.xxx(xxxx)) CHLINSTYPE(CURRENT) RQMNAME() STATUS(RETRYING) STOPREQ(NO) SUBSTATE(OTHER) XMITQ(PL81N)

Check the output contents to both error logs.

*AMQ9633E is output to the Windows(SDR) side, and the reason why the channel could not be started is that the certificate was invalid. ----- amqcrhna.c : 789 -------------------------------------------------------- AMQ9633E: Bad SSL certificate for channel 'PL92W.PL81N' .... (e) an OCSP responder has indicated that it is revoked .... The details of the certificate which could not be validated are '[Class=]GSKVALMethod::X509[Issuer=]EMAIL=support@sd.pulsarintegration.com, CN=www.sd.pulsarintegration.com,O=Pulsar Integration SD Inc.,ST=Sydney,C=AU[#=]01[Subject=]CN=www.sd.pulsarintegration.PL81N.com,O=Pulsar Integration PL81NA Inc.,ST=Sydney,C=AU' The certificate validation error was 575032 .... ----- amqccisa.c : 8789 ------------------------------------------------------- *AMQ9633 is also output to the NonStop(RCVR) side, and the reason why the channel could not be started is that the certificate was invalid. ----- amqrmrsa.c : 926 -------------------------------------------------------- AMQ9633: Bad SSL certificate for channel '????'. .... (e) an OCSP responder has indicated that it is revoked .... The certificate validation error was 1042. .... ----- amqcciso.c : 3968 -------------------------------------------------------

After all, you can see that the same error message is output on each machine regardless of the direction of sending and receiving the channel.
Error code 575032 indicates certificate revocation.

If you want to undo the revocation after validation, use a backup of index.txt to undo it. Don't forget to restart the OCSP responder as well.

$ cp -p index.txt.old index.txt
$ cat index.txt
V 310802082027Z 01 unknown /C=AU/ST=Sydney/O=Pulsar Integration PL81NA Inc./CN=www.sd.pulsarintegration.PL81N.com
V 310824073603Z 02 unknown /C=AU/ST=Sydney/O=Pulsar Integration PL81NA Inc./CN=www.sd.pulsarintegration.PL81Nec.com
*After restoring index.txt, restart the OCSP responder.

to the top