私はクライアントがxmlリクエストを送信してxmlレスポンスを返すことができるxmlゲートウェイを公開するウェブサイトで作業しています。このウェブサイト/会社は、より大きな組織によって購入され、インフラストラクチャに移行されました。既存の本番サイトでは、特定の認証局によるSSL証明書を使用していますが、大規模な組織では異なる認証局から発行された証明書を使用しています。クライアントの1人でテストを実行しようとしましたが、SSLハンドシェイクエラーが発生しています。オリジナルの開発者は、元のSSL証明書を元の状態に復元し、新しい証明書を使用しないことが唯一の方法であると言います。私はこの問題を診断するためのガイダンスや指示を探しているので、どんな助けもありがたいです。SSL XMLゲートウェイ - SSL証明書のハンドシェイクエラー
開発者の言うとおり、この説明から分かりやすいですが、問題はその問題です。
これが正確に起こっていることを確認するには、wiresharkキャプチャを実行してから、フローをSSLとしてデコードします。問題は、クライアントがサーバーから送信された証明書を信頼せず、接続を拒否した場合にwiresharkのハンドシェイクでその証明書が表示されることです。
Javaクライアントを使用している場合は、-Djavax.net.debug=sslで実行して、java内からのsslメッセージを確認できます。
これが本当に問題の場合は、クライアントのトラストストアを構成して、証明書をサーバー（元のサーバー）に送信させる必要があります。この構成はもちろん可能である場合
...これはアプリケーションに依存
UPDATE：あなたは新しいCAに移行まあ場合
、あなたのインターフェイスで新しい証明書を展開すなわち、申し訳ありませんが、それは "あなたの" - サーバーサイドエラーを意味しています。
IMHO可能であれば、事前指定期間に古い証明書を再デプロイし、新しい CAで署名された新しい証明書に移行する予定のすべての関係者と通信して、クライアントが中断しないようにします
その後、新しい証明書を受け入れることができるようにクライアントアプリケーションを「修正」するのは、その期間内の責任です。これは設定と同じくらいシンプルにすることができます。つまり、証明書をトラストストアにインポートすること、コードを変更してクライアントアプリケーションを再構築すること（たとえば、発行された新しい証明書にコードが検証する拡張子がないか、CNが変更された等）。
それは、古い証明書を再デプロイすることができない場合、あなただけのすべての利害関係者への変更を伝えるために持っており、（前述したように）、その後、彼らはそれに応じて「修正」する必要があり
はご回答いただきありがとうございます。私はそれがクライアントとサーバーの間の信頼の問題でなければならないと信じています。我々の問題は、クライアントが会社と協力して情報を提出する独立した組織であることです。技術的には、トラストストアを設定するためのアクセス権がありません。この場合、あなたは何をお勧めしますか？ – mreyeros
私は何かについてはっきりしていません。サーバー側で作業していて、新しい証明書を使用し始めたため、クライアントの接続が壊れましたか？クライアントはどのように作成されましたか？WSDL経由ですか？ – Cratylus
私は明確にして詳細を提供していますが、最初に.net 1.1を使用して開発されたasp.net Webサイトがあります。このWebサイトにはXMLリクエストを受け取っているaspxページがあり、これを処理してxml応答をクライアントを呼び出す。クライアントと言うと、私は第三者を意味し、私たちに情報を送る別の会社かもしれません。私は、これがあなたがクライアントのトラストストアについて言及したものに関連している可能性があると考えています。新しい証明書はおそらく各クライアントトラストストアで設定する必要があります。 – mreyeros