1

Java で Apache CXF を使用して Web サービス クライアントを作成する必要があります。問題は、SSL セッションを適切に接続できないように見えることです。完全に失敗するか、アプリケーションデータが送信された後にサーバーが送信されたものを解読できないか、サーバーからの応答を読み取れません。

ただし、.NET に組み込まれた単純な SOAP テスト クライアントを使用して同じトランザクションを試行すると、すべてがスムーズに実行されます。

サーバーは二重認証を使用しています。

すべてが Windows 証明書ストア (windows-MY および windows-ROOT) に格納されている証明書ベース (x509) です。

はい、二重認証は確かにクライアントとサーバーの認証です。

これまでのところ、SunMSCAPI の代わりに bountyCastle プロバイダーを使用するとさらに進んでいるように見えますが、それでもクライアント認証を機能させることはできません。

クライアントのプラットフォーム CXF 2.2.9、Sun JDK 1.6_21 サーバー IIS 6 ASP.NET 残念ながら、収集できるのはすべてです。サーバーを制御できないため、そのまま使用する必要があります。

更新 現在JKSキーストアを使用していますが、まだ問題が発生しています。認証プロセスの一環として、クライアントが自分の証明書をサーバーに送信していないようです。その結果、サーバーから 403.7 エラーが発生します。

面白いことに、このエラー メッセージは HTML ページとして表示されます。このページは、解読する前に解読する必要があります。

4

3 に答える 3

4

おそらく、二重認証とは、サーバー証明書認証（より一般的）に加えてクライアント証明書認証を使用していることを意味します。

どちらの側で使用されているプラ​​ットフォームのバージョンと、適用されているパッチを知っておくと便利です。

問題の一部は、 CVE-2009-3555への再ネゴシエーションの修正（または修正の欠如）に起因する可能性があります。

問題は、クライアント証明書の再ネゴシエーションに使用されたTLSでの再ネゴシエーションの初期設計の欠陥です。クライアント証明書を取得するには、2つの方法があります。サーバーが最初のTLSハンドシェイク中に要求するか、後続のハンドシェイク中に要求します（たとえば、要求の目的や目的がわかったら）。特定の制限区域にアクセスしようとした場合）。2番目の方法は再ネゴシエーションです。残念ながら、その点でTLSプロトコルの設計にセキュリティ上の欠陥があり、 RFC5746で説明されているTLS拡張のおかげで修正されました。

欠陥が最初に開示されたとき（2009年11月頃）、Sun JavaやOpenSSLなどの一部のプラットフォームとライブラリは、再ネゴシエーションを単に許可しないクイックフィックスを公開しました（したがって、クライアント証明書の最初のネゴシエーションのみが機能します）。その後、RFC 5746が作成されると、これらのライブラリはこの拡張機能をサポートする実装の展開を開始しました。

私の知る限り、IISとそのWebフレームワークにおけるMicrosoftのデフォルトは、最初のネゴシエーションではなく、再ネゴシエーションを使用することでした。さらに、再ネゴシエーションを無効にする（既知の脆弱性を効果的に維持する）初期修正を展開しませんでした。パッチを公開したのはごく最近のことです（デフォルトではまだ古い実装に耐性があります）：Microsoft SecurityBulletinMS10-049-クリティカル。

このMicrosoftセキュリティブログにも問題の説明があります：http： //blogs.technet.com/b/srd/archive/2010/08/10/ms10-049-an-inside-look-at-cve- 2009-3555-the-tls-renegotiation-vulnerability.aspx

基本的に、新しい再ネゴシエーションスタイルのみを持つ、または再ネゴシエーションがまったくないスタックから、古いネゴシエーションスタイルのみをサポートするサーバーと通信しようとしている場合、それは機能しません。

netshサーバーがIISまたは同様の環境を使用して実行されている場合は、とそのclientcertnegotiation=enableオプションを使用して最初のクライアント証明書ネゴシエーションをオンにできる場合があります。

于 2010-08-26T16:18:21.897 に答える
3

Java は OS 証明書ストアに依存せず、独自のものを使用する必要があります。

これにより、自己署名証明書がインポートされます。

cd JAVA_HOME/jre/lib/security
keytool -import -file server_cert.cer -keystore cacerts
于 2010-08-26T15:50:30.263 に答える
0

これを回答として投稿しますが、問題を回避するために.NETの例が実際にハックを実行していたため、ループに陥ったため、質問が適切に定式化されていないことに気付きました。

適切な質問は

証明書の要求を要求しないサーバーで Java にクライアント側認証を実行させるにはどうすればよいですか?

答えは実際には私たちの目の前にありますが、答えにたどり着くには正しい質問が必要です!!

非常に役立つ情報を提供してくれたブルーノに感謝します。

解決策は、次の 2 つの質問に要約できます。

Java HTTPS クライアント証明書認証

IIS からの 403.7 エラーを引き起こすクライアント SSL 認証

要求されない場合、クライアントは証明書を送信することは「想定されていません」が、キーストアのクライアント証明書を微調整して、次の内容を含めることがわかりました。

  • すべての拡張子を持つクライアント証明書
  • クライアント秘密鍵
  • クライアントの完全な認証チェーンの連結。

これらすべてを同じ証明書ストアにプッシュし、キーストアとして使用します。次に、証明書チェーンをトラスト ストアとして再度読み込みます。そこからはうまくいくはずです。これはまだ失敗の可能性があると言われています。この特定の問題を解決する最も安全な方法は、承認された CA のリストを提供することにより、サーバーがクライアントから認証証明書を積極的に要求するようにすることです。

これが同じ問題で立ち往生している可能性のある他の誰かに役立つことを願っています.

于 2010-08-27T19:22:52.050 に答える