握手失败可能由于多种原因而发生：
- 客户端和服务器使用的密码套件不兼容。这将要求客户端使用（或启用）服务器支持的密码套件。
- 使用的 SSL 版本不兼容（服务器可能仅接受 TLS v1，而客户端只能使用 SSL v3）。同样，客户端可能必须确保它使用 SSL/TLS 协议的兼容版本。
- 服务器证书的信任路径不完整；服务器的证书可能不受客户端信任。这通常会导致更详细的错误，但很有可能。通常解决方法是将服务器的 CA 证书导入到客户端的信任存储中。
- 该证书是为不同的域颁发的。同样，这会导致更详细的消息，但我将在此处说明修复方法，以防这是原因。在这种情况下，解决方案是让服务器（它似乎不是您的）使用正确的证书。
由于无法查明根本故障，因此最好打开-Djavax.net.debug=all标志以启用已建立的 SSL 连接的调试。打开调试后，您可以查明握手中的哪些活动失败了。
Update
根据现有的详细信息，问题似乎是由于颁发给服务器的证书与根 CA 之间的证书信任路径不完整造成的。大多数情况下，这是因为信任库中不存在根CA的证书，导致证书信任路径无法存在的情况；该证书本质上不受客户端信任。浏览器可以发出警告，以便用户可以忽略它，但 SSL 客户端的情况并非如此（例如HttpsURL连接类，或任何 HTTP 客户端库，如 ApacheHttpComponents 客户端).
大多数这些客户端类/库将依赖 JVM 使用的信任存储来进行证书验证。在大多数情况下，这将是cacerts文件位于 JRE_HOME/lib/security 目录中。如果已使用 JVM 系统属性指定信任存储的位置javax.net.ssl.trustStore，那么该路径中的存储通常是客户端库使用的存储。如果您有疑问，请查看您的Merchant类，并找出它用于建立连接的类/库。
将服务器的证书颁发 CA 添加到此信任存储应该可以解决该问题。你可以参考我的回答有关获取工具的相关问题为了这个目的，但是Java 密钥工具实用程序足以达到这个目的。
Warning：信任存储本质上是您信任的所有 CA 的列表。如果您放入不属于您不信任的 CA 的证书，则在私钥可用的情况下，可以解密到具有该实体颁发的证书的站点的 SSL/TLS 连接。
更新 #2：了解 JSSE 跟踪的输出
JVM 使用的密钥库和信任库通常列在最开始，有点像下面这样：
keyStore is :
keyStore type is : jks
keyStore provider is :
init keystore
init keymanager of type SunX509
trustStore is: C:\Java\jdk1.6.0_21\jre\lib\security\cacerts
trustStore type is : jks
trustStore provider is :
如果使用了错误的信任库，那么您需要将服务器的证书重新导入到正确的信任库，或者重新配置服务器以使用列出的证书（如果您有多个 JVM，则不建议这样做，并且它们都用于不同的用途）需要）。
如果您想验证信任证书列表是否包含所需的证书，则有一个相同的部分，其开头为：
adding as trusted cert:
Subject: CN=blah, O=blah, C=blah
Issuer: CN=biggerblah, O=biggerblah, C=biggerblah
Algorithm: RSA; Serial number: yadda
Valid from SomeDate until SomeDate
您需要查找服务器的 CA 是否是主题。
握手过程将有一些显着的条目（您需要了解 SSL 才能详细了解它们，但为了调试当前问题，知道 ServerHello 中通常报告握手失败就足够了。
1. 客户你好
初始化连接时将报告一系列条目。 SSL/TLS 连接设置中客户端发送的第一条消息是 ClientHello 消息，通常在日志中报告为：
*** ClientHello, TLSv1
RandomCookie: GMT: 1291302508 bytes = { some byte array }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA]
Compression Methods: { 0 }
***
请注意使用的密码套件。这可能不得不同意与您的merchant.properties 文件中的条目相同，因为银行的图书馆可能采用相同的约定。如果使用的约定不同，则无需担心，因为如果密码套件不兼容，ServerHello 会进行说明。
2.服务器你好
服务器用 ServerHello 进行响应，这将指示连接设置是否可以继续。日志中的条目通常具有以下类型：
*** ServerHello, TLSv1
RandomCookie: GMT: 1291302499 bytes = { some byte array}
Cipher Suite: SSL_RSA_WITH_RC4_128_SHA
Compression Method: 0
***
记下它选择的密码套件；这是服务器和客户端均可使用的最佳套件。如果出现错误，通常不会指定密码套件。服务器的证书（以及可选的整个链）由服务器发送，并且可以在条目中找到：
*** Certificate chain
chain [0] = [
[
Version: V3
Subject: CN=server, O=server's org, L=server's location, ST =Server's state, C=Server's country
Signature Algorithm: SHA1withRSA, OID = some identifer
.... the rest of the certificate
***
如果证书验证成功，您将看到类似以下内容的条目：
Found trusted certificate:
[
[
Version: V1
Subject: OU=Server's CA, O="Server's CA's company name", C=CA's country
Signature Algorithm: SHA1withRSA, OID = some identifier
上述步骤之一不会成功，从而导致握手失败，因为握手通常在此阶段完成（并非真正完成，但握手的后续阶段通常不会导致握手失败）。您需要找出哪个步骤失败了，并发布适当的消息作为问题的更新（除非您已经理解该消息，并且知道如何解决它）。
