2 つの証明書チェーンがインストールされている Java キーストアがあります。CSR は CA によって生成および署名され、対応する CA の両方の証明書がインストールされています。ただし、ポート上のアプリケーションに要求を送信すると、1 つの証明書のみが表示されますが、キーストアの両方の証明書を表示して、優先する証明書に対して認証できるようにする必要があります。
これについて支援が必要です
答え1
余談ですが、CAはCSRに署名するのではなく、証明書に署名します。部分的にCSR に基づいていますが、部分的にはそうではありません (両方の部分が重要です)。
あなたは言う '1つのCSR が生成されました。実際に 1 つの CSR (1 つのキーに対して) を作成し、その CSR に対して 2 つの証明書 (それぞれチェーンを含む可能性があります) を取得し、両方の証明書チェーンをストアの 1 つの秘密キー エントリにインストールした場合、2 番目の証明書が最初の証明書に置き換わり、ストアには 2 番目の証明書のみが存在することになります。
代わりに、2 つの秘密鍵と 2 つの CSR (各鍵に 1 つ) を生成し、各 CSR に対して証明書チェーンを取得して対応する秘密鍵にインストールしたため、実際には異なる証明書チェーンを持つ 2 つの秘密鍵があり、両方を確認したいと考えていると想定します。疑わしい場合は、 を使用しkeytool -list [-v]て確認してください。
SSL（現在のTLS）プロトコルはそうしません; サーバーは、1 つの「エンティティ」(サーバー) 証明書と、存在する場合はそのチェーン証明書のみを送信し、1 回のハンドシェイクで対応する秘密鍵を証明します。
あなた5月2つのリクエストを実行でき、それぞれが1つ必要な証明書チェーン:
証明書のサブジェクト名/SAN 名が異なり、クライアントが SNI 拡張機能を使用している場合 (最近のブラウザでは使用されていますが、他のソフトウェアでは使用されている場合と使用されていない場合があります)、Java 8 サーバーは SNI に一致する証明書を優先します。ほとんどのクライアント (OpenSSL は除く) は、常に SNI を接続先のホスト名と同じにします。そのため、複数のホスト名を同じサーバーにポイントするように、たとえば
hostsファイルや unbound などを使用して、名前解決を (一時的に?) 変更する必要がある場合があります。証明書が異なるキー タイプ (RSA、DSA、EC) 用であり、クライアントが 1 つのキー タイプを使用する暗号スイートのみを提供する場合、Java サーバーはそのキー タイプ用の証明書を使用します。一部のクライアントでは、提供される暗号スイートを簡単に制御できますが、そうでないクライアントもあります。
同様に、証明書チェーンが異なる署名アルゴリズム（のセット）を使用し、クライアントが SignatureAlgorithms 拡張機能を使用して TLS1.2 を実装している場合、Java 7 以降のサーバーは SigAlgs を満たす証明書チェーンを優先します。ただし、SigAlgs を簡単に選択できるクライアントは知りません。また、CA は、発行する証明書のチェーンで使用される署名アルゴリズムの選択肢をほとんど提供していません。