握手失败可能是由于多种原因引起的：
- 客户端和服务器使用的密码套件不兼容。这将要求客户端使用（或启用）服务器支持的密码套件。
- 正在使用不兼容的SSL版本（服务器可能仅接受TLS v1，而客户端只能使用SSL v3）。同样，客户端可能必须确保使用兼容版本的SSL / TLS协议。
- 服务器证书的信任路径不完整；客户端可能不信任服务器的证书。这通常会导致更冗长的错误，但是很有可能。通常，解决方法是将服务器的CA证书导入到客户端的信任库中。
- 证书是针对其他域发布的。同样，这将导致出现更详细的消息，但是如果这是原因，我将在此处进行说明。在这种情况下，解决方案将是使服务器（似乎不是你的服务器）使用正确的证书。
由于无法确定潜在的故障，因此最好打开该 -Djavax.net.debug=all标志以启用对已建立的SSL连接的调试。启用调试后，你可以查明握手中的哪些活动失败。
更新资料
根据现在可用的详细信息，看来该问题是由于颁发给服务器的证书和根CA之间的证书信任路径不完整所致。在大多数情况下，这是因为信任存储中不存在根CA的证书，导致无法存在证书信任路径的情况。证书基本上不受客户端信任。浏览器可以发出警告，以便用户可以忽略此警告，但是SSL客户端（例如
HttpsURLConnection类或任何HTTP客户端库（例如
Apache HttpComponents Client））并非如此。
这些客户端类/库中的大多数都将依赖JVM使用的信任库来进行证书验证。在大多数情况下，这将是
cacertsJRE_HOME / lib / security目录中的文件。如果信任库的位置已使用JVM系统属性指定
javax.net.ssl.trustStore，则该路径中的库通常是客户机库使用的库。如果你有疑问，请查看你的Merchant班级，并弄清用于建立连接的班级/图书馆。
将服务器的证书颁发机构CA添加到此信任存储区应该可以解决此问题。你可以在有关为此目的获取工具的相关问题上参考我的回答，但是
Java keytool实用程序足以满足此目的。
警告：信任存储区实质上是你信任的所有CA的列表。如果你输入的证书不属于你不信任的CA，则如果私钥可用，则可以解密到具有由该实体发行的证书的站点的SSL / TLS连接。
更新＃2：了解JSSE跟踪的输出
JVM所使用的密钥库和信任库通常在一开始就列出，如下所示：
keyStore is : keyStore type is : jkskeyStore provider is : init keystoreinit keymanager of type SunX509trustStore is: C:Javajdk1.6.0_21jrelibsecuritycacertstrustStore type is : jkstrustStore provider is :
如果使用了错误的信任库，那么你需要将服务器的证书重新导入到正确的证书中，或者将服务器重新配置为使用列出的证书（如果你有多个JVM，则不建议这样做，并且所有JVM都用于不同的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中通常报告出一个handshake_failure就足够了。
- ClientHello
初始化连接时，将报告一系列条目。客户端在SSL / TLS连接设置中发送的第一条消息是ClientHello消息，通常在日志中报告为：
*** ClientHello, TLSv1Randomcookie: 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 }***请注意使用的密码套件。这可能必须与商人.properties文件中的条目一致，因为银行的图书馆可能采用相同的约定。如果使用的约定不同，则无需担心，因为如果密码套件不兼容，ServerHello会声明。
- ServerHello
服务器以ServerHello响应，这将指示连接设置是否可以继续。日志中的条目通常为以下类型：
*** ServerHello, TLSv1Randomcookie: GMT: 1291302499 bytes = { some byte array}Cipher Suite: SSL_RSA_WITH_RC4_128_SHACompression Method: 0***注意它选择的密码套件；这是服务器和客户端均可使用的最佳套件。如果出现错误，通常不指定密码套件。服务器的证书（以及可选的整个链）是由服务器发送的，可以在以下条目中找到：
*** Certificate chainchain [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
上述步骤之一将不会成功，从而导致handshake_failure，因为握手通常在此阶段完成（不是真的，但是握手的后续阶段通常不会导致握手失败）。你需要找出失败的步骤，然后发布适当的消息作为问题的更新（除非你已经理解了该消息，并且知道该怎么做）。
分享改善这个答案
