javax.net.ssl.SSLHandshakeException：致命的なアラートを受信しました：bad_certificate でエンドポイントとの相互認証に失敗するIssue サードパーティのエンドポイントに SSL 接続を確立する場合、インスタンスの HTTP クライアントプロトコルのデフォルト設定が、定義されたハンドシェイクに干渉する可能性があります。 クライアントが認証のためにサーバー証明書を要求すると、証明書署名要求 (CSR) が生成されます。CSR に応答するために、サーバーは 2 つの一意の暗号化キーを生成します。サーバーへのメッセージを暗号化するために使用される公開鍵とメッセージを復号化するために使用される秘密鍵です。両方のキーがキーストアに保持されます。キーを使用して、クライアントの安全なメッセージを復号化し、サーバーで読み取りができるようにします。HTTPS になるすべての送信接続は、キーストアを確認してその公開認定を提供することで、認定を検証し、トラストストア証明書を使用して相互の信頼性を検証します。クライアントとサーバーとの間で安全なリンクを確立するために、サーバーは証明書を対応する秘密鍵と照合します。サーバーのみが秘密鍵にアクセスできるため、サーバーはクライアントからのデータを復号化できます。 これらの設定がエンドポイントの設定と一致しない場合に問題が発生し、bad_certificate エラーが発生する可能性があります 症状 この問題は、次のような場合に発生します。 非相互認証サービスを使用したシステムへの接続が正常に機能する。複数のキーストアがインストールされている。相互に認証されたエンドポイントに対して SOAP UI やその他のツールでテストすると、bad_certificate エラーが発生する。プロパティを空に設定するか、SSL ハンドシェイクのエンドポイントセットアップと一致させることで、問題が解決する。 Causeこれには、いくつかの理由が考えられます。以下は、ポート 443 の com.glide.certificates.DBKeyStoreSocketFactory ソケットファクトリに MYHTTPS を登録するコマンドの例です。 データベースキーストアファクトリは、SSL 交換プロセス中に相互認証用のクライアント証明書を提供するために使用されます。 glide.httpclient.protocol.myhttps.class = "com.glide.certificates.DBKeyStoreSocketFactory" glide.httpclient.protocol.myhttps.port = "4433" この場合、エンドポイント SSL ソケットファクトリが 4433 と異なると、エラーで失敗する可能性があります。Resolutionプロパティ glide.httpclient.protocol.myhttps.class および glide.httpclient.protocol.myhttps.port の値を空にします。 これが機能しない場合は、相互認証プロファイルの値をエンドポイントの設定に合わせます。 署名済み CA 証明書をエンドポイントのインスタンスにアップロードし、証明書レコードを個別に作成したら、既存の myhttps プロトコルプロファイルのキーストア参照フィールドを更新するだけです。テスト環境や本番環境用に別のプロトコルプロファイルを作成すると、ターゲットシステムに接続しようとしたときに接続エラーが発生することがあります。そのため、予期せぬ動作を防ぐために、myhttps という名前のプロトコルプロファイルを 1 つだけ保持し、署名済み CA キーストアへの参照を更新します。また、認証の問題が発生する可能性があるため、キーストアのファイル名には小文字のみを含めるようにしてください。 注意：デフォルトの HTTPS プロトコルソケットファクトリを上書きすると、すべての送信 HTTPS 接続に影響します。 通常、これは望ましくありません。Related LinksSOAP 送信メッセージの SSL (コミュニティ)相互認証 (docs)