2017-06-10 17 views
0

アプリケーションAがWebサービスアプリケーションを呼び出します。キーストアとトラストストアの利点と同じJKSファイル

相互認証。

私たちはアプリケーション証明書を持っています。 jksファイル内の唯一の証明書コンテンツです。

アプリケーションAキーストアとトラストストアと同じjksファイルが使用されています。それは正常に動作しています。

私がここで理解しているのは、appBがappBを呼び出すと、appBがその証明書を送信します。 この証明書はappAによって受け入れられます。appA trsustoreでは、同じ証明書CAは、APPAは、クライアント認証の一環としてAPPBに証明書を送信するときに、同じことが

が正しいSSLのこのような理解です起き、その後

C.

を命名しました。皆さんはアドバイスをお願いしますか?ありがとう

答えて

0

正しく理解されていますが間違っています。キーストアはプライベートです。それはあなたの秘密鍵を含んでいます。トラストストアには、公開証明書だけが含まれます。両方の目的で同じファイルを使用しないでください。あなたの身元とあなたが信頼する人物は全く異なる2つの問題です。

+0

こんにちは@EJP、返信ありがとう、これは私が不明になっているポイントです。私は他のスレッドでも同様の秘密鍵の問題を読んでいます。 jksには証明書が1つしか含まれていないためです。私の学習の理解ごとに、証明書は公開鍵だけを含んでいます。だから、ここにセキュリティ上の問題はないはずですか? keystoreとtrustore jksの両方には証明書だけの公開鍵しかありません。 – rahul90

+0

いいえ、それは間違っていますか?私が書いたものを読んでください。キーストアには、秘密鍵が含まれています。鍵ペアを作成してからCSRを生成した後、署名してから、署名付きの証明書をインポートしました。 – EJP

+0

こんにちは@EJP、ありがとう、私はSSLのonemoredoubt私は片方向SSLで、クライアントは、サーバー証明書が表示され、クライアントの証明書上のCAnameがtrustore.Ifの一部であることを確認すると、これはデジタル署名で行われます。疑いはありますか?秘密鍵はデジタル署名を行うために使用されますか?それはCAの秘密鍵かサーバーBの秘密鍵ですか?なぜなら、CAの秘密鍵が使用されていると、それはCAが実際にそれを主張しているものであることを検証するだけなのだから。サーバBの秘密鍵が使用されている場合のみ、そのことを言うことができます。 – rahul90

関連する問題