問題タブ [truststore]

SSLソケット接続をセットアップしようとしています（そしてクライアントで次のことを行っています）

1. 署名されたクライアント証明書を取得するために証明書署名要求を生成します

2. これで、秘密鍵（CSR中に使用）、署名されたクライアント証明書、およびルート証明書（帯域外で取得）ができました。

3. 秘密鍵と署名されたクライアント証明書を証明書チェーンに追加し、それを鍵マネージャーに追加します。トラストマネージャーへのルート証明書。しかし、私は悪い証明書エラーを受け取ります。

私は正しい証明書を使用していると確信しています。署名されたクライアント証明書をトラストマネージャーにも追加する必要がありますか？それを試してみましたが、まだ運がありません。

ここで作成する必要のある証明書チェーンの種類はありますか？
これらのコンポーネントを備えたp12もあり、非常によく似たコードを使用して、キーマネージャーに秘密鍵を追加し、p12からトラストマネージャーにルート証明書を追加して、それを機能させることができました。しかし今、私はそれをp12なしで動作させる必要があります。

編集：スタックトレースが要求されました。これで十分だといいのですが。（注：ファイル名をマスクしました）

自己署名証明書を使用してキーストアを作成し、証明書をエクスポートして、IPアドレスのエイリアスを使用して証明書を再インポートしました。

このサーバー内からこのサーバーのアドレス]/....にある別のサービスに電話をかけたい。

呼び出しのクライアント側に自分自身を信頼させることができません。トラストストアを指定するにはどうすればよいですか？

server.xmlの重要な部分は次のとおりです。

httpsを使用してこのサーバーからそれ自体にサービスを呼び出そうとすると、このエラーが発生します。

PKIXパスの構築に失敗しました：sun.security.provider.certpath.SunCertPathBuilderException：要求されたターゲットへの有効な認証パスが見つかりません

ありがとう

キーストアが秘密鍵に対してどのように機能するかを理解しています。基本的に、キーストアを作成し、キーを生成/署名/保存します。エイリアスに基づいて、コンテナ（JBoss、tomcat、WebLogic、またはWebSphere）は初期化中に適切なキーをロードします。私の質問はトラストストアと関係があります。コンテナが、たとえばThawteによって署名されたキーを持つ外部Webサイトにリクエストを送信した場合、コンテナは、SSLハンドシェイクを完了するためにトラストストアから提供する公開キーをどのように知るのでしょうか。トラストストアには間違いなくエイリアスがありますが、コンテナがリモートサイトへの接続を呼び出すときに、エイリアスを使用して一致する公開鍵を見つけるかどうかは本当に疑わしいです。

クライアント アプリで Axis 1.4 を使用して SOAP 呼び出しを行っています。HTTPS 経由でサービスを呼び出しています。自己署名証明書を使用するサービスもあれば、認証局によって発行された証明書を使用するサービスもあります。

この回答のコードを使用して、自己署名証明書を信頼ストアに追加しました。私の問題は、トラストストアがすべての呼び出しに使用されていることです-CAからの有効な証明書を持つサーバーへの呼び出しであっても。

自己署名証明書を持つサーバーにのみトラストストアを使用するように Axis に指示する方法はありますか?

組み込みのjettyサーバーとクライアント間のクライアント証明書認証に取り組んでいます。どちらもキーストアを使用します。クライアント証明書は、CA によって署名されたサーバーの証明書によって署名されます。Jetty は 2 つの方法を使用して、クライアント証明書 javax.net.ssl.SSLEngine を認証します。これは動作しているようで、上記のコードも使用します。

もちろん、この 2 番目の方法を使用する必要があります... では、このコードに集中しましょう。これは、署名付き証明書を検証する良い方法ですか? ここに私のキーストアのダンプがあります:

クライアントキーストア:

サーバーのトラストストア:

これらのキーストアについてはよくわかりませんが、別のものを試してみました (CA 証明書をクライアントの証明書チェーンに追加し、証明書をトラストストアに追加)、検証はまだ失敗します。そして、これらのキーストアを使用すると、検証の最初の方法 (SSLEngine) が機能するようです。

デバッグ出力は大きすぎてここに記載できませんが、スタックトレースは次のとおりです。

失効を無効にするか、(最初の証明書ではなく) 最後の証明書を X509CertSelector として設定すると、コードは機能しますが、何をしているのかわかりません。

jetty コードについて疑い始めていますが、私は証明書と SSL ハンドシェークの専門家ではないため、不適切なキーストア/トラストストアから発生する可能性もあります。そのため、私は jetty のボードでイシューを作成せず、コードを変更する必要があることを確認するために、以前にここで質問しました。

また、Java で署名された証明書を検証する方法を知っておくと役立つ場合があります。

Google クラウド メッセージ サーバー経由で Android デバイスにプッシュ通知を送信しようとしています。

そのために使用する URL は次のとおりです。

私たちのエンタープライズ アプリケーションでは、デフォルトの CA 機関を使用せず、SSLContext プロパティによってロードされるトラストストア ファイルに、セキュリティ上の理由から信頼する各エンティティを手動で追加します。トラストストアに GCM 証明書を追加したいと考えています。

その URL から証明書を取得する方法がわかりません。ページが別の非 SSL ページにリダイレクトされるため、Chrome/Firefox のエクスポート方法が機能していないようです。

誰かが解決策を持っていますか？

複数のクライアント（クライアント証明書を持つクライアント）で使用されているアプリケーションがあります。このアプリケーションは、HTTPSを介して（HttpClientを使用して）Webサービスと通信することになっています。このWebサービスで認証するには、クライアント証明書を提供する必要があります。前に述べたように、各クライアントには異なるクライアント証明書があり、現在のクライアントの証明書を使用する必要があります。説明されていることを実行している次のコードがあります。

わかりました、動作しています。しかし、このサービスにリクエストを送信するスレッドはたくさんあります。時々それは私にいくつかの問題を与えます。そのため、アプリケーションごとにHttpClientを1つだけ持つ方がよいと多くの人が言っているのを見つけました。これは、次のように実行できます。

このようにして、接続プールを備えたHttpClientを使用できます。しかし、このアプローチを使用して、特定の要求に対してクライアント証明書を選択するにはどうすればよいですか？前もって感謝します。

編集：

なぜこれをやっているのか説明しようと思います。時々問題が発生します。サーバーはWebサーバーとの通信を停止し、しばらくすると再び動作を開始します。Webサービスを呼び出す前に多くの処理が行われることに注意することが重要です。したがって、すべての処理を実行するスレッドを作成するプールされたエグゼキュータがあります。ジョブが完了すると、このスレッドはWebサービスと通信する別のスレッドを作成します。したがって、最初のスレッドはタイムアウト（thread.join（timeout））で2番目のスレッドに参加します。最初のスレッドがウェイクアップすると、まだ完了していない場合は、Webサービスと通信しようとしているスレッドに割り込んでいます。私はこれを実装した人ではありませんが、完了要求にタイムアウトを与えることになっています。私の開発マシンでは、このサービスを使用して多くのクライアントをシミュレートするJMeterテストを作成し、JConsoleを接続して何が起こっているかを確認しました。300のタスクが実行された後（そのうちのいくつかは失敗しました）、エグゼキューターのプールによって作成されたスレッドは停止しました。しかし、多くのスレッドが存続しており、10分後に死んでしまいました。スタックトレースを見ると、HttpClientに関連していることがわかりました。次に、検索を開始し、アプリケーション全体で1つのHttpClientのみを使用して、接続をプールする方がよいと言う人を見つけました。接続するポートを検索しているときにHttpClientがロックされており、最初のスレッドによって中断されていると思います。すると、どういうわけか、長時間ロックします。エグゼキュータのプールによって作成されたスレッドが停止しました。しかし、多くのスレッドが存続しており、10分後に死んでしまいました。スタックトレースを見ると、HttpClientに関連していることがわかりました。次に、検索を開始し、アプリケーション全体で1つのHttpClientのみを使用して、接続をプールする方がよいと言う人を見つけました。接続するポートを検索しているときにHttpClientがロックされており、最初のスレッドによって中断されていると思います。すると、どういうわけか、長時間ロックします。エグゼキュータのプールによって作成されたスレッドが停止しました。しかし、多くのスレッドが存続しており、10分後に死んでしまいました。スタックトレースを見ると、HttpClientに関連していることがわかりました。次に、検索を開始し、アプリケーション全体で1つのHttpClientのみを使用して、接続をプールする方がよいと言う人を見つけました。接続するポートを検索しているときにHttpClientがロックされており、最初のスレッドによって中断されていると思います。すると、どういうわけか、長時間ロックします。接続をプールします。接続するポートを検索しているときにHttpClientがロックされており、最初のスレッドによって中断されていると思います。すると、どういうわけか、長時間ロックします。接続をプールします。接続するポートを検索しているときにHttpClientがロックされており、最初のスレッドによって中断されていると思います。すると、どういうわけか、長時間ロックします。

編集：

これは私がJConsoleで見るものです。今回は、100個のタスクのみを開始し、この状態のスレッドは15個です。

外部の承認済みクライアントに Web サービスを公開する Java アプリを作成しました。Web サービスは、WS-security と証明書認証を使用します。基本的に、私たちはカスタム認証局として機能します。サーバー上に Java トラストストアを維持し、クライアントの証明書に署名して追加します。現在、WS クライアントが証明書署名要求をアップロードする必要がある手動登録プロセスがあります。CSR に署名し、コマンド ラインから keytool を使用して Java トラストストアに証明書を追加し、CA 証明書と共に署名済み証明書をクライアントに返します。次に、クライアントは秘密鍵を使用して SOAP メッセージ ペイロードに署名し、署名付き証明書をメッセージに埋め込みます。サーバー側はデジタル署名を復号化し、埋め込まれた証明書が署名されていること、およびクライアントの要求を満たす前にトラストストアと一致することを確認します。

(手作業のため) 多少の痛みはありますが、このセットアップは正常に機能しています。ルート CA 証明書が間もなく期限切れになることに気付きました。そのため、メンテナンス ポリシーの設定を検討しています。自己署名ルート CA 証明書を更新するにはどうすればよいですか? 新しいものを作成してオリジナルを置き換える必要があるようです。これは、すべてのクライアントが新しい証明書を受け取り、新しい CA 証明書をインポートする必要があることに影響します。それは正しい理解ですか、それとも状況を処理するためのより良い方法があるかどうか?

問題がある場合は、openssl を使用して元のキー ペアを生成しました。

tomcat6で実行されているサーバーがあり、クライアント証明書を信頼する必要があります。HttpConnectorの「truststoreFile」属性を使用してトラストストアを構成しました。

クライアント証明書は中間証明書によって署名され、中間証明書はルート証明書によって署名されます。3つはすべて、opensslを使用して作成されたサンプル証明書です。

サーバーのトラストストアにはクライアント証明書と中間証明書のみを含めましたが、クライアントはこれら2つだけでサーバーと通信できます。サーバーがクライアント証明書を信頼するために、ルート証明書がサーバーのトラストストアにある必要はありません。

プログラムで使用されている現在のトラストストアを教えてくれる関数はありますか？Windowsでは、デフォルトのトラストストアはJAVA_HOME \ lib \ security\cacertsにあります。

ただし、デフォルトはさまざまな方法で変更できます。

• -Djavax.net.ssl.keyStoreコマンドラインでの使用

• Keystoreクラスを使用します。

• プログラムが、アプリケーションが実行されているアプリケーションサーバーで実行されている場合、そのパネルを介してストアパスを設定できます。

• プログラムがTomcatで実行されている場合、Tomcatの設定によってトラストストアが変更される可能性があります。

そして他の多くの方法。

現在アクティブなトラストストアのディスクパスを見つけるためのプログラム的な方法はありますか？