English

実践習得 IBM MQの基本

SSL/TLSの構成(5)OCSP

※本連載は最新のmqpgf/mqpcfに基づいて改定されることがあります。 常に最新バージョンをダウンロードしてご使用ください。

IBM MQでは失効(リボーク)したデジタル証明書を確認する手段として、OCSP(Online Certificate Status Protocol)と LDAP (Lightweight Directory Access Protocol) サーバー上の CRL(Certificate Revocation List)と ARL(Authority Revocation List)を参照する方法の2つをサポートしています。

OCSP 証明書を管理している場所(CA)でOCSPリスポンダーを起動し、照会された証明書の状況を応答として返却する仕組み
LDAP上のCRL/ARLの参照 CRL/ARLを証明書を管理している場所(CA)で生成し、LDAP上に配置する。

※ここで、CRLとARLのそれぞれの用途は下記になります。

CRL CA が発行する利用者(サーバー)証明書の失効リスト
ARL CA(認証局)証明書に対しての権限取り消しリスト

この回では、OCSPを使用して対向側チャネルのサーバー証明書が失効された場合の挙動を検証します。 ここまでの検証テストでは、Windows,Linux,HPE NonStopの各サーバー上でイントラネットCAを構築しましたので、それぞれのマシン上のCAでOCSPリスポンダーを起動します。 opensslコマンドはOCSPリスポンダーとして起動しておくことが可能ですので、その機能を使用します。
OCSPリスポンダーを参照する方法は大きく下記がサポートされます。

AIA証明書拡張の使用 検査対象の証明書内の AuthorityInfoAccess (AIA) 証明書拡張にOCSPリスポンダーのURIを指定する。
認証情報オブジェクトの使用 OCSPリスポンダーへのURLを定義した認証オブジェクトのネームリストを、キューマネージャーのSSLCRLNLに設定する。
MQAIR構造体のOCSPResponderURLの使用 MQクライアント・アプリケーションで、MQAIR(Authentication Information Record)構造体のOCSPResponderURLに、OCSPリスポンダーのURLを設定する。

ここではサーバー側では、「AIA証明書拡張」よりもより自由度の高い「認証情報オブジェクト」を、クライアント接続では、「MQAIR構造体のOCSPResponderURL」を使用して検証を実施します。
これ以降、前回までのSSL/TLSを使用したサーバー間接続、クライアント接続を使用する為の手順が実行されていることを前提としますので、実行してない場合は、これまでの章を参考に実施しておいてください。 楕円曲線を使用しているか、使用していないかは問いません。


OCSP構成の為の前提条件と制約事項

IBM MQでOCSPを利用する為に、その前提条件と制約事項をまとめます。 既にOCSPについての理解を持っている場合には、認識済みのことも含まれてるかもしれません。

単一のOCSPリスポンダーにのみ接続可能 IBM MQからOCSPリスポンダーに接続するには、キューマネージャー・プロパティの SSLCRLNL に、OCSPリスポンダーへのURL を定義した AUTHINFO の NAMELIST を設定します。 NAMELIST になっていますが、複数のOCSPリスポンダーに接続することはできません。 複数の AUTHINFO を含む NAMELIST を SSLCRLNL に指定しても、IBM MQはその先頭の AUTHINFO のみを参照します。
OCSPリスポンダーの要件 OCSPリスポンダーへの参照はキューマネージャー毎に指定しますので、チャネル毎に設定するということはできません。 全てのチャネルに接続される相手側のサーバー証明書の失効(リボーク)を検知したい場合は、それらの全ての情報を持つOCSPリスポンダーに接続する必要があります。
証明書チェックの対象 OCSPの証明書チェックは相手サーバーの証明書に対してのみ行われます。 自サーバーの証明書を発行したCAの OCSPリスポンダーに接続する必要はありません。
対象チャネルの種類 双方向認証の場合、接続/データの送受信の方向は関係ありません。 どちらの場合でも、相手サーバーから送信される証明書に対してのチェックが行われます。
OCSP参照時の自IPアドレス AUTHINFO にはチャネル・プロパティーの LOCLADDR の様なプロパティーは存在しません。 その為、接続に使用するローカル・アドレス(含、HPE NonStopでのTCPプロセス)にキューマネージャーで使用するものとは別のものを使用することはできません。 デフォルトで認識されるアドレスが使用されます。

最初にサーバー間接続を構成してみます。 これまでに作成した検証環境では、各サーバー上でCAを構築し、サーバー証明書を発行しました。 その為、各サーバーのCA上でOCSPリスポンダーを起動し、対向側のキューマネージャーからそれぞれ接続します。
検証に使用するサーバーは、Windows/Linux/HPE NonStopいずれでも手順は同じですので、任意に選択してください。

fig 14.1


opensslを使用したOCSPリスポンダーの起動と確認

最初にIBM MQを使用せずにOCSP Reponderの基本動作を確認します。


OCSPリスポンダーの起動

OCSPリスポンダーの起動方法はWindows, Linux, HPE NonStopで全て同じで、opensslコマンドの ocspユーティリティを使用します。 それぞれで作成したCAのディレクトリに移動して下記コマンドを実行してください。 "-ignore_err"を指定しないと、起動時にエラーが発生して起動できない場合があります。 また、ポート・スキャンが実行された時のエラー終了を避ける効果もあります。 openssl.cnfは使用しませんので、OPENSSL_CONF環境変数の設定は必要ありませんが、WARNINGが気になる場合は、CA作成時に使用したopenssl.cnfを参照させます。 CAのプライベート・キーのパス・フレーズを聞かれるので入力すると、OCSPクライアントからの接続待ちの状態になります。 下記はHPE NonStopで起動した例ですが、Windows、Linuxでも同じコマンドラインです。
※MQ8 for HPE NonStopでインストールされるopensslは、少なくとも本稿執筆時点ではOCSPレスポンダー・モードはサポートされておらず、起動しようとしても失敗します。 HPE NonStop上では別途インストールされた他のopensslを使用してください。 OCSPのクライアント・モードはMQ8にバンドルされているopensslコマンドでも問題なく使用できます。

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

*オプションの説明
ocsp: オンライン証明書状態プロトコルユーティリティを実行。
-index indexfile: indexfile は、証明書失効情報を含む ca フォーマットのテキストインデックスファイル。
※index オプションが指定された場合、ocsp ユーティリティはレスポンダモードとなります。 それ以外ではクライアントモードで動作します。
-CA file: CA 証明書を指定します。
-rsigner file: OCSP レスポンスに署名する証明書を指定します。
-rkey file: OCSP レスポンスに署名する秘密鍵を指定します。
-port portnum: OCSP リクエストをリスンするポートを指定します。


OCSPリスポンダーへの接続の確認

OCSPによるサーバー証明書の接続/検証が問題なく行われるかどうかを検証します。 openssl ocspコマンドは、-indexオプションが指定された場合はレスポンダ・モードとなり、指定されない場合はクライアント・モードになります。 このクライアント・モードを使用して、起動済みのOCSPリスポンダーに接続させることで動作検証できます。 検証対象の対向側サーバーの証明書を取得できる場合は、FTP等で転送してコマンドに指定します。
下記はLinuxからNonStopのサーバー証明書を検証した例です。 NonStop側のCA証明書(cacert_ns.pem)とサーバー証明書(PL81NA.pem)をLinux側から指定して検証します。
opensslのバージョンにより"WARNING: Status times invalid."という警告メッセージが出力される場合がありますが、opensslコマンドのバグによるものの様ですので、無視して構いません。

$ 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

$

*オプションの説明
ocsp: オンライン証明書状態プロトコルユーティリティを実行。
-issuer filename: 最新の発行者の証明書を指定。 指定した証明書は PEM フォーマットであることが必要。 このオプションは複数指定可能です。
-cert filename: 検証する証明書のファイル名を指定。
-url responder_url: リスポンダURLを指定する。 HTTPとHTTPS (SSL/TLS) のURLが指定できます。
-CAfile file, -CApath pathname: file あるいは pathname にはCA 証明書を指定します。 これらはOCSPレスポンスで署名の検証に使用されます。

※-CAfile/-CApathは、証明書チェーンに中間CA証明書が含まれる場合に指定します。 証明書チェーンには今回はCAはroot証明書のみなので、-CAfile/-CApath 指定は省略できますが、opensslのバージョンによってはroot証明書を指定しないと、"Response Verify Failure"になる場合があります。

OCSPレスポンダーへ接続するURLが正しいかどうかを確認するのみであれば、ダミーで接続先のCAで発行されていない証明書をコマンドに指定しても構いません。 OCSPレスポンダー側のCAのindex.txtにない証明書が指定された場合は、「Response verify OK」が出力された後、「xxxx.pem: unknown」が表示されます。

$ 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

$


CAにて証明書を失効(リボーク)させる

次に、想定通りに失効(リボーク)が検知されるかどうかをチェックします。
失効(リボーク)はopensslコマンドで行います。 失効させるとCAのindex.txtに記録されている、そのCAで発行された証明書情報のリストの先頭の文字が"V"から"R"に変更されます。
下記はLinuxサーバーで失効(リボーク)させ、他サーバーから証明書を送信していますが、それぞれどんなプラットフォームでも手順は同じです。

$ 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

*オプションの説明
ca: CAの基本的な機能、X.509証明書や証明書失効リストの発行を行う。
-config filename: openssl構成ファイルを指定。
OPENSSL_CONF環境変数より優先。
-cert filename: CA証明書が格納されているファイル名を指定。
-keyfile filename: CAの秘密鍵が格納されているファイル名を指定。
-revoke filename: 失効させる証明書が格納されたファイル名を指定。

opensslのリスポンダー・モードは、起動時にのみ index.txt ファイルを読み込みますので、証明書を失効(リボーク)させた後は、OCSPリスポンダーを手動で再起動が必要です。 忘れないで実行しておいてください。
※OCSPリスポンダーは停止後、直ぐに起動すると、エラーが発生する場合があります。 その場合は、一定時間待って起動します。

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

※CTRL+Cなどで中断
※失効させた後、再起動
$ 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...

先にお話ししておきますと、テストが終わって失効(リボーク)を取り消すには、index.txtのバックアップ・ファイル(index.txt.old)からindex.txtファイルを復元します。 opensslコマンドは証明書に対しての作業を行う度にindex.txtのバックアップ・ファイルを一つ作成します。 index.txtの復元後、OCSPリスポンダーを再起動します。

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

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


OCSPによる証明書検証の確認

接続の確認と同様のコマンドを発行します。 "revoked"が表示されることを確認します。

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

ここでOCSPクライアントが表示するステータスを整理しておきます。

OCSPリスポンダーへの接続失敗 Error connecting BIO
Error querying OCSP responder
Error <etc.>
OCSPリスポンダー応答の検証結果 Response verify OK 応答の検証に成功
Response Verify Failure 応答の検証に失敗

証明書の状況 説明
Good 証明書は有効です。
Revoked 証明書は取り消されています。
Unknown この結果になるのは、次の 3 つのうちのいずれかが原因です。
・IBM MQ が OCSP 応答側にアクセスできない。
・OCSP 応答側が応答を送信したが、IBM MQ が応答のデジタル署名を検証できない。
・OCSP 応答側が、その証明書に関する失効データを保持していないことを示す応答を送信した。


MQサーバー間接続でのOCSPの使用

既にTLSを使用したサーバー間接続チャネルが双方向で作成され、通信可能な状態になっていることを前提にします。 その状態で、OCSPリスポンダーへの接続を定義する認証情報を作成して、キューマネージャーが参照できるようにします。


サーバー間接続でのOCSPリスポンダー参照の構成

下記は定義例です。 AUTHINFOのOCSPURLプロパティーに対抗側のOCSPリスポンダーへの参照を定義します。 接続を検証する双方でお互いにOCSPによる証明書検証を行っても良いですし、片側だけでも構いません。 OCSPURLの設定値以外は同じです。 各オブジェクトのネーミングはもちろん自由です。

※認証情報オブジェクトの定義。 OCSPURLには対向先のサーバー証明書を発行したCAで起動されているOCSPリスポンダーへの参照を設定します。 送信元アドレス(LOCLADDR)は指定できません。
mqpcf mqsc -qm <qmgr name> -s "def authinfo(<authinfo name>) authtype(OCSP) OCSPURL('http://<ip addr or hostname>:2560') replace"

※認証情報のネームリストの作成
mqpcf mqsc -qm <qmgr name> -s 'def namelist(<namelist name>) names(<authinfo name>) replace'

※作成したネームリストをキュー・マネージャーのSSLCRLNL(証明書失効リスト・ネームリスト)に設定
mqpcf mqsc -qm <qmgr name> -s 'alter qmgr SSLCRLNL(<namelist name>)'

※SSL/TLS設定情報のリフレッシュ。
チャネル接続中に実施する場合は、コマンド・サーバーからリフレッシュの実行結果を受信するまでに時間がかかる場合があります。 その場合、コマンドサーバーからの応答の返却が遅れ、デフォルトの10秒の応答待ち時間経過後、2033(MQRC_NO_MSG_AVAILABLE)を受け取ります。

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

その場合は"-w"で応答受信までの待ち時間を指定します。
mqpcf mqsc -qm <qmgr name> -wi 60 -s 'refresh security type(SSL)'

*オプションの説明
mqsc: MQSCコマンド文字列の実行またはMQSCスクリプトファイルの読み込み
-s: MQSCコマンド文字列を指定。
-wi: コマンド・サーバーからの応答受信までの待ち時間。

チャネルが正常に開始されることを確認します。 下記は、WindowsマシンとNonStopマシン間での接続の例です。

$ 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)


OCSPリスポンダーに接続できない場合の挙動

片側のOCSPリスポンダーを停止してみます。 TLSは双方向認証ですので、送受信両方のチャネルがTLSで接続できなくなるはずです。

例として、Windows側のOCSPリスポンダーを停止してみます。 NonStopサーバー側のチャネルがWindows側のサーバー証明書をチェックできなくなります。

\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 ※CTRL+Cで停止。
\openssl\winca>

両マシンの送信側(SDR)チャネルからチャネルを再起動して状況を確認します。
まず、NonStop側の送信側(SDR)チャネルを再起動してみます。

※NonStop側の送信側(SDR)からチャネルの再起動 $ 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 ※チャネル・ステータスはBINDINGがしばらく続いた後、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(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)

双方のエラー・ログへの出力内容を確認します。

※Windows(RCVR)側には AMQ9665E が出力され、リモート・サイドからTLS接続がクローズされたことが報告されます。 ----- amqcrhna.c : 789 -------------------------------------------------------- AMQ9665E: SSL 接続が、チャネル '????' のリモート・エンドによってクローズされま した。 ----- amqccisa.c : 8789 ------------------------------------------------------- ※NonStop(SDR)側には AMQ9716 が出力され、チャネルが開始できなかった理由として、失効状況が確認できなかった ことが表示されます。 ------------------------------------------------------------------------------- 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 -------------------------------------------------------


次に、反対のWindows側の送信側(SDR)チャネルを再起動してみます。

※Windows側の送信側(SDR)からチャネルの再起動 >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 ※チャネル・ステータスはBINDING、SUBSTATE(SSLHANDSHK)がしばらく続いた後、RETRYINGになります。 >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)

双方のエラー・ログへの出力内容を確認します。

※Windows(RCVR)側には AMQ9665E が出力され、リモート・サイドからTLS接続がクローズされたことが報告されます。 ----- amqcrhna.c : 789 -------------------------------------------------------- AMQ9665E: SSL 接続が、チャネル 'PL92W.PL81N' のリモート・エンドによってクローズ されました。 ----- amqccisa.c : 8789 ------------------------------------------------------- ※NonStop(RCVR)側には AMQ9716 が出力され、チャネルが開始できなかった理由として、失効状況が確認できなかった ことが表示されます。 ----- 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 -------------------------------------------------------

チャネルの送受信の方向にかかわらず、各マシンで同じエラーメッセージが出力されていることが確認できます。

fig 14.2


証明書が検証できない場合(Unknown)の動作の変更

証明書が検証できない(Unknown)になるのは、この様にOCSPリスポンダーに接続できないケースも含め、既にご紹介済みですが、下記3つのケースがあります。

Unknown ・IBM MQ が OCSP 応答側にアクセスできない。
・OCSP 応答側が応答を送信したが、IBM MQ が応答のデジタル署名を検証できない。
・OCSP 応答側が、その証明書に関する失効データを保持していないことを示す応答を送信した。

IBM MQでは、証明書が検証ステータスが Unknown の場合の挙動を、qm.ini ファイルの SSL スタンザに OCSPAuthentication パラメータを設定することで変更することが可能です。 REQUIRED(デフォルト)/OPTIONAL/WARNが設定でき、それぞれの場合の動作は下記の様に変更されます。

REQUIRED 接続を拒否し、エラー・メッセージ AMQ9716 を出力する。
OPTIONAL TLSチャネルが開始が許可され、警告や SSL イベント・メッセージは生成しない。
WARN TLSチャネルは開始されるが、警告メッセージ AMQ9717 をエラー・ログに出力します。


OCSPリスポンダーへの照会結果が失効(Revoke)だった場合の挙動

例として、NonStop側のサーバー証明書を失効させてみます。 双方向認証ですので、送受信両方のチャネルが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

OCSPリスポンダーの再起動を忘れないようにしてください。

$ 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 ※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...

両マシンの送信側(SDR)チャネルからチャネルを再起動して状況を確認します。
まず、NonStop側の送信側(SDR)チャネルを再起動してみます。

※NonStop側の送信側(SDR)からチャネルの再起動 $ 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 ※チャネル・ステータスは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)

双方のエラー・ログへの出力内容を確認します。

※Windows(RCVR)側には AMQ9633E が出力され、チャネルが開始できなかった理由として、証明書が不正であったことが 表示されます。 ----- amqcrhna.c : 789 -------------------------------------------------------- AMQ9633E: チャネル '????' の SSL 証明書が不正です。 .... (e) OCSP 応答側はそれが失効したことを示している。 .... 検証できなかった証明書の詳細は '[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' です。 証明書の検証エラーは 575032 です。 .... ----- amqccisa.c : 8789 ------------------------------------------------------- ※NonStop(SDR)側にも AMQ9633 が出力され、チャネルが開始できなかった理由として、証明書が不正であったことが 表示されます。 ------------------------------------------------------------------------------- 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 -------------------------------------------------------


次に、反対のWindows側の送信側(SDR)チャネルを再起動してみます。

※Windows側の送信側(SDR)からチャネルの再起動 >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 ※チャネル・ステータスは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)

双方のエラー・ログへの出力内容を確認します。

※Windows(SDR)側には AMQ9633E が出力され、チャネルが開始できなかった理由として、証明書が不正であったことが 表示されます。 ----- amqcrhna.c : 789 -------------------------------------------------------- AMQ9633E: チャネル 'PL92W.PL81N' の SSL 証明書が不正です。 .... (e) OCSP 応答側はそれが失効したことを示している。 .... 検証できなかった証明書の詳細は '[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' です。 証明書の検証エラーは 575032 です。 .... ----- amqccisa.c : 8789 ------------------------------------------------------- ※NonStop(RCVR)側にも AMQ9633 が出力され、チャネルが開始できなかった理由として、証明書が不正であったことが 表示されます。 ----- 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 -------------------------------------------------------

やはり、チャネルの送受信の方向にかかわらず、各マシンで同じエラーメッセージが出力されていることが確認できます。
エラーコード 575032 は証明書の失効(リボーク)を示します。

fig 14.3

検証後に失効を取り消す場合は、index.txtのバックアップを使用して元に戻します。 OCSPリスポンダーの再起動も忘れないでください。

$ 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
※index.txtをリストア後、OCSPリスポンダーの再起動する。

このページの先頭へ

このページの先頭へ