2

を使用して、を介しWebSphere MQ v6.0.1.1てJavaクライアントからアクセスできるように構成しました。クライアントとサーバーを別のマシンと同じマシンで試しました。クライアント側で同じ例外は発生しませんでしたが、接続の問題に関連しています。サーバー側では、ログに何もありません。JNDIJMSSSL

別のマシンクライアント側エラー:Thread pool thread #0, Exception sending alert: java.net.SocketException: Software caused connection abort: socket write error

*** ServerHelloDone
*** Certificate chain
***
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1
Thread pool thread #0, WRITE: TLSv1 Handshake, length = 141
SESSION KEYGEN:
PreMaster Secret:
0000: 03 01 DB 7F 1B 78 46 24   D1 B3 7F 8F E4 2B 2D 35  .....xF$.....+-5
0010: 1B EB FF C9 01 C9 EC 12   07 0F F9 88 A9 12 45 77  ..............Ew
0020: 22 AE 79 17 C2 9D 4C 97   04 3E BA 91 1F 14 68 44  ".y...L..>....hD
CONNECTION KEYGEN:
Client Nonce:
0000: 50 76 7B FB 0D 45 F0 8D   EF 54 E0 AB 2C 3A D4 7D  Pv...E...T..,:..
0010: 24 52 FB FB 4F F4 1D E4   CC 2C 4E BA 8B CA 3E 54  $R..O....,N...>T
Server Nonce:
0000: 00 00 00 00 8F 53 C4 4D   2F 2F 41 AA EB 0A 80 2D  .....S.M//A....-
0010: D0 E4 51 2A CC BC EE 94   92 BD CD E0 9B C9 EB 3D  ..Q*...........=
Master Secret:
0000: 9D 93 ED F3 8A 97 39 7F   71 5F 34 52 30 A6 8E 38  ......9.q_4R0..8
0010: BC 17 59 28 78 63 AA 66   63 D0 EE 1C C6 54 CA D1  ..Y(xc.fc....T..
0020: F2 F0 ED 7E D7 81 33 C6   E3 1B 7C 46 C0 FB C8 5C  ......3....F...\
Client MAC write Secret:
0000: 57 56 3D 05 B1 27 BE 56   A8 FD 07 64 0A 96 62 F2  WV=..'.V...d..b.
0010: AE AF B5 98                                        ....
Server MAC write Secret:
0000: F5 C7 B2 D2 79 11 90 6C   C8 FD 86 8B E5 AE 59 71  ....y..l......Yq
0010: B2 A7 AB D3                                        ....
Client write key:
0000: 54 FD FD 8B C2 B4 8B 3F   38 23 25 5A 8A 41 26 9B  T......?8#%Z.A&.
Server write key:
0000: 6D 9C C0 97 ED 21 3F 0E   0A FB E2 2B EE C0 5F 01  m....!?....+.._.
... no IV used for this cipher
Thread pool thread #0, WRITE: TLSv1 Change Cipher Spec, length = 1
*** Finished
verify_data:  { 182, 85, 56, 238, 250, 233, 155, 119, 224, 254, 23, 196 }
***
Thread pool thread #0, WRITE: TLSv1 Handshake, length = 36
Thread pool thread #0, READ: TLSv1 Change Cipher Spec, length = 1
Thread pool thread #0, READ: TLSv1 Handshake, length = 36
*** Finished
verify_data:  { 215, 140, 30, 150, 82, 161, 85, 160, 127, 189, 226, 74 }
***
%% Cached client session: [Session-1, SSL_RSA_WITH_RC4_128_SHA]
Thread pool thread #0, setSoTimeout(120000) called
Thread pool thread #0, WRITE: TLSv1 Application Data, length = 150
Thread pool thread #0, READ: TLSv1 Application Data, length = 56
Thread pool thread #0, WRITE: TLSv1 Application Data, length = 48
Thread pool thread #0, called close()
Thread pool thread #0, called closeInternal(true)
Thread pool thread #0, SEND TLSv1 ALERT:  warning, description = close_notify
Thread pool thread #0, WRITE: TLSv1 Alert, length = 22
Thread pool thread #0, Exception sending alert: java.net.SocketException: Software caused connection abort: socket write error

同じマシンクライアント側エラー:Thread pool thread #0, Exception sending alert: java.net.SocketException: Broken pipe

サーバーがすでに接続を閉じているのに、クライアントが書き込みを行っているようです。

編集:

10/10/12  2:26:23 PM - Process(10995.12) User(mqm) Program(amqrmppa)
AMQ9631: The CipherSpec negotiated during the SSL handshake does not match the
required CipherSpec for channel 'SSL.CHANNEL'.

EXPLANATION:
There is a mismatch between the CipherSpecs on the local and remote ends of
channel 'SSL.CHANNEL'. The channel will not run until this mismatch is
resolved. The CipherSpec required in the local channel definition is
'RC4_SHA_US'. The name of the CipherSpec negotiated during the SSL handshake is
'RC4_SHA_US'. A code is displayed if the name of the negotiated CipherSpec
cannot be determined.
ACTION:
Change the channel definitions for 'SSL.CHANNEL' so the two ends have matching
CipherSpecs and restart the channel. If the certificate in use by one end of
the channel is a Global Server Certificate, then the negotiated CipherSpec may
not match that specified on either end of the channel. This is because the SSL
protocol allows a Global Server Certificate to automatically negotiate a higher
level of encryption. In these cases specify a CipherSpec which meets the
requirements of the Global Server Certificate.
----- amqccisa.c : 851 --------------------------------------------------------
10/10/12  2:26:23 PM - Process(10995.12) User(mqm) Program(amqrmppa)
AMQ9999: Channel program ended abnormally.

EXPLANATION:
Channel program 'SSL.CHANNEL' ended abnormally.
ACTION:
Look at previous error messages for channel program 'SSL.CHANNEL' in the error
files to determine the cause of the failure.
----- amqrmrsa.c : 468 --------------------------------------------------------

編集2:

     1 : DIS CHANNEL(SSL.CHANNEL) SSLCIPH
AMQ8414: Display Channel details.
   CHANNEL(SSL.CHANNEL)                    CHLTYPE(SVRCONN)
   SSLCIPH(RC4_SHA_US)

暗号は以下を使用してクライアント側を使用しましたJMSAdmin

DEFINE QCF(QCF_NAME) SYNCPOINTALLGETS(YES) HOSTNAME(HOST) PORT(1414) TRANSPORT(client) QMANAGER(MYQMGR) CHANNEL(SSL.CHANNEL) SSLCIPHERSUITE(SSL_RSA_WITH_RC4_128_SHA)

SSLCipherSpecsとCipherSuites RC4_SHA_USに基づくものは一致しているようSSL_RSA_WITH_RC4_128_SHAです。

4

1 に答える 1

0

QMgrと同じホストでクライアントを実行している場合、ネットワークスタックではなく、バインディングモード(共有メモリ)を使用して接続する可能性があります。バインディングモード接続はネットワークスタックを使用しないため、SSLは違いを生じません。

どちらの場合もクライアントがネットワーク経由で接続していると仮定すると、クライアントの構成がインスタンスごとに異なることを除いて、SSL接続に影響を与えるサーバー上のクライアントの場所については何もありません。クライアントはまだネットワークスタックを通過しており、QMgrのリスナーに接続要求を提示しています。クライアントは同じ方法でキーストアを見つけ、QMgrが見るのはリスナーに提示された接続要求だけです。したがって、2つのクライアントインスタンス間で異なる結果が得られる場合は、構成の不一致を探してください。

WMQでSSL接続をデバッグするための私の方法は、次の手順に進む前に、各手順が機能することを確認して、次の手順を実行することです。

  1. SSLなしでチャネルを実行します。これにより、チャネル名のスペルが正しいこと、エンドポイント間にネットワークルートが存在すること、QMgrのリスナーが実行されていること、およびクライアントが正しいポートを指していることが検証されます。
  2. SVRCONN定義をに設定してチャネルを実行しSSLCAUTH(OPTIONAL)ます。これにより、ブラウザと同様の匿名SSL接続が実行されます。QMgrはクライアントに証明書を提示しますが、証明書を要求しません。これにより、QMgrが証明書を見つけることができ、クライアントがトラストストアを見つけて、QMgrの証明書を適切に検証できることが検証されます。
  3. SVRCONNチャネルをに設定しSSLCAUTH(REQUIRED)ます。これにより、クライアントはキーストアを見つけ(最後のステップではトラストストアのみが必要)、証明書を見つけることができるようになりました。また、QMgrがクライアントの証明書を検証できるようにする必要があります。

最後の2つの手順の違いは、SSLクレデンシャル交換を一度に一方向でのみテストすることにより、問題を切り分けるのに役立ちます。

これが発生すると、「ログには何も記録されない」とおっしゃっています。どのログ?エラーログは2セットあります。1つはのサーバーグローバルログで{WMQ home}/errors、もう1つはのQMgrエラーログ{WMQ home}/QMgrs/{QMgr name}/errorsです。MQがエラーに関連付けられたQMgrを識別できる場合、エラーログエントリがQMgrのエラーログに作成されます。ただし、SSL接続が要求されると、MQは、SSL接続が完了するまで接続が要求したQMgrを認識しません。このため、サーバー側での多くのSSLネゴシエーションエラーがグローバルエラーログに報告されます。

上記の手順を実行して、失敗しているSSLクレデンシャル交換を特定し、QMgrファイルとグローバルエラーログファイルの両方でエラーログエントリを探すことをお勧めします。これで問題が解決しない場合は、失敗したプロセスのステップと、それらが見つかったログによって識別されたエラーログエントリに注意して、質問を更新してください。

また、MQのV6は先月サービスを終了しました。サポートされているバージョンのWMQクライアントとサーバーに移行すると、PMRを開くことができ、Java / JMSのパフォーマンスが大幅に向上し、SHA-2ハッシュやによってサポートされる新しい楕円曲線暗号などのより安全な暗号を使用できるようになります。 GSKit 8. WMQ V6はサポートされていないため、追加のフィックスパックは最大で1つだけリリースされます。その後、そのバージョンのセキュリティの脆弱性は対処されません。SSLを使用している場合、セキュリティはある程度重要であり、新しい脆弱性が発見された場合に修正を受け取るバージョンを使用することをお勧めします。

更新
グローバルサーバー証明書に関する質問の更新に対応するには、WMQがSSL/TLSを実装する方法を理解する必要があります。接続が確立されると、TLSネゴシエーション(SSLを指定した場合、WMQはSSL暗号を使用してTLSセッションを実行します)が仕様に従い、仕様により暗号スイートのネゴシエーションが可能になります。グローバルサーバー証明書を使用する場合、証明書は許容可能な最小の暗号強度を指定でき、これがネゴシエーションに影響します。

TLSセッションが正常に完了すると、接続はWebSphereMQに渡されます。その場合にのみ、QMgrは「接続が要求されているQMgrは何ですか?」などのチャネルパラメータをチェックします。または、さらに重要なことに、「接続のネゴシエートされた暗号仕様はチャネル定義と一致しますか?」通常、クライアントとサーバーの不一致に基づいて失敗します。グローバルサーバー証明書では、ネゴシエートされた暗号仕様と、証明書で指定されている許容可能な最小値との不一致が原因で失敗する可能性があります。

エラーメッセージが示しているのは、クライアントによって指定された暗号スイートがチャネルで指定された暗号仕様と正確に一致し、グローバルサーバー証明書が使用する暗号強度よりも大きい最小暗号強度を指定しているために接続に失敗する可能性があることです。クライアントとQMgr。これについては、インフォセンターのCipherspecの不一致でさらに詳しく説明しますが、この場合、エラーメッセージはインフォセンターとほぼ同じくらい有益です。

于 2012-10-10T10:53:32.207 に答える