現在、次の問題により、サーバーへの接続に問題があります。
サーバーに接続しようとすると、次のエラーが返されました。MQRC_SSL_INITIALIZATION_ERROR
WireSharkを介して詳細に分析したところ、クライアントがSSL v2を使用してサーバーに接続しようとしているのに対し、サーバーはSSL V3しか受け入れられず、接続が拒否されていることがわかりました。
ドキュメントを確認しましたが、.Net クライアントがサポートする SSL バージョンに関する情報を見つけることができませんでした。
SSL バージョンが .Net MQ クライアントから制御されているかどうかを確認したいのですが、そうであれば、SSL v3 経由で接続するように構成するにはどうすればよいですか?
ありがとう。
WMQ は SSL V3.0 と TLS V1.0を少なくとも V6.0 以降、おそらくそれ以前からサポートしているため、あなたの結論に同意するかどうかはわかりません。これは、クライアントとサーバー間の構成の不一致である可能性が高くなります。SSL/TLS の問題を解決するために推奨する手順は次のとおりです。
WMQ で SSL 接続をデバッグするための私の方法は、次の手順を実行して、次の手順に進む前に各手順が機能することを確認することです。
SSLCAUTH(OPTIONAL)ます。これにより、ブラウザと同様の匿名 SSL 接続が実行されます。QMgr はクライアントに証明書を提示しますが、クライアントは証明書を返送する義務はありません。これにより、QMgr がその証明書を見つけられること、およびクライアントがそのトラスト ストアを見つけて、QMgr の証明書を適切に検証できることが検証されます。(注: QMgr は常にクライアント証明書を要求し、クライアント証明書が存在する場合はクライアントは常にそれを送信します。このテストを実行するには、署名者証明書を含むがアプリケーションの個人証明書を含まないクライアントのキーストアのコピーを使用します。キーストアをコピーし、コピーから個人証明書を削除します。オリジナルは削除しないでください! )SSLCAUTH(REQUIRED)ます。これにより、クライアントはキーストアを見つけ (最後のステップでは信頼ストアのみが必要でした)、証明書を見つけることができるようになる必要があります。また、クライアントの証明書を検証できる QMgr も必要です。手順 2 と 3 の違いは、一度に一方向のみで SSL 資格情報の交換をテストすることで、問題を特定するのに役立ちます。これにより、問題が個人証明書と公開証明書のどちらに存在するか、およびチャネルのどちら側にあるかを特定できます。ほぼすべての問題は、この 2 つのステップで解決されます。
UPDATE
質問に回答するためのメモ。SSL/TLS で使用される証明書には 2 種類あります。個人証明書には秘密鍵が含まれており、渡されることはありません。公開証明書は、公開鍵を含む証明書であり、自由に配布できます。秘密鍵はキーストアに保持されます。公開鍵 (通常、これらは CA のルートおよび中間証明書です) はトラスト ストアに格納されます。場合によっては、これらは別個のファイルです。たとえば、Java と JMS では、JSSE プロバイダーは、環境内でキーストアとトラスト ストアを指す変数を探します。Java と JMS では、キーストア変数とトラスト ストア変数が同じファイルを指す可能性があります。
Java 以外の WebSphere MQ サーバーおよびクライアントの場合、キーストアとトラスト ストアは 1 つの場所に結合されます。多くの場合、kdb ファイルと呼ばれますが、実際には、KDB を含むいくつかのファイルで構成される CMS キー データベースです。この場合、「キーストア」は実際には、キーストアとトラスト ストアを組み合わせた省略形です。.Net クライアントの場合、MQEnviornmentでキーストアの場所とその他の SSL プロパティを設定します。
SSL/TLS ハンドシェイクでは、サーバーは常に接続要求に応答して公開証明書を送信します。次に、クライアントは、最初に署名と有効期限を確認し、次にトラスト ストアで証明書に署名したものを探して、その証明書を検証する必要があります。証明書に署名したものが中間署名者証明書 (それ自体が何かによって署名されている) である場合、検索はルート証明書に到達するまで署名者証明書チェーンを続けます。サーバーが認証されていると仮定すると、クライアントに証明書を提示させ、サーバーにそれを検証させることにより、同じ手順が逆に適用されます。
ステップ 2 でプロセスが失敗した場合、上記のプロセスの知識を使用してデバッグできます。QMgr は、まずキーストアでその証明書を見つけて、クライアントに提示する必要があります。QMgr が証明書を見つけられない場合、AMQERR01.LOG ファイルにエラーが記録されます。ステップ 2 で問題が発生した場合は、必ず最初に QMgr 側を確認してください。
QMgrがその証明書を見つけた場合、次のステップは、クライアントがそのトラスト ストアを見つけることができる必要があり、そのトラスト ストア内で必要な署名者証明書チェーンを見つける必要があるということです。これが失敗した場合、それを示すエラーがクライアント側にあるはずです。たとえば、クライアント環境を設定する際の一般的なエラーは、.kdb 拡張子を含むファイル名全体を指定することです。これが発生すると、QMgr は[keystorename].kdb.kdb存在しないものを探します。もう 1 つの一般的なエラーは、個人証明書が鍵ストアに存在するが、ラベルが間違っていることです。Java 以外の WMQ クライアントは、リテラル文字列ibmwebspheremqとそれに続く小文字のユーザー ID から構成されるラベル名で証明書を検索します。たとえば、ユーザー ID が のTRob場合、証明書ラベルは次のようになります。ibmwebspheremqtrob. これはキーストア内の証明書のラベルであり、証明書の共通名や識別名の他のフィールドではないことに注意してください。
使用中のクライアントのタイプによって、これらは Windows エラー ログ、ローカル MQ エラー ログ、またはその他の場所にある可能性があります。クライアント側のエラーが見つからない場合は、WMQ トレースもオプションです。