收到致命警报：handshake_failure 通过 SSLHandshakeException

Question

我的授权 SSL 连接有问题。我已经创建了 Struts Action，它使用客户端授权的 SSL 证书连接到外部服务器。在我的行动中，我试图将一些数据发送到银行服务器，但没有任何运气，因为服务器导致我出现以下错误：

 error: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

我的 Action 类中的方法将数据发送到服务器

//Getting external IP from host
    URL whatismyip = new URL("http://automation.whatismyip.com/n09230945.asp");
    BufferedReader inIP = new BufferedReader(new InputStreamReader(whatismyip.openStream()));

    String IPStr = inIP.readLine(); //IP as a String

    Merchant merchant;

    System.out.println("amount: " + amount + ", currency: " + currency + ", clientIp: " + IPStr + ", description: " + description);

    try {

        merchant = new Merchant(context.getRealPath("/") + "merchant.properties");

    } catch (ConfigurationException e) {

        Logger.getLogger(HomeAction.class.getName()).log(Level.INFO, "message", e);
        System.err.println("error: " + e.getMessage());
        return ERROR;
    }

    String result = merchant.sendTransData(amount, currency, IPStr, description);

    System.out.println("result: " + result);

    return SUCCESS;

我的 merchant.properties 文件：

 bank.server.url=https://-servernameandport-/
https.cipher=-cipher-

keystore.file=-key-.jks
keystore.type=JKS
keystore.password=-password-
ecomm.server.version=2.0

encoding.source=UTF-8
encoding.native=UTF-8

我第一次以为这是证书问题，我将它从.pfx 转换为.jks，但我有同样的错误，没有任何变化。

原文由 Denees 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

握手失败可能由于多种原因而发生：

• 客户端和服务器使用的不兼容密码套件。这将要求客户端使用（或启用）服务器支持的密码套件。
• 使用的 SSL 版本不兼容（服务器可能只接受 TLS v1，而客户端只能使用 SSL v3）。同样，客户端可能必须确保它使用兼容版本的 SSL/TLS 协议。
• 服务器证书的信任路径不完整；客户端可能不信任服务器的证书。这通常会导致更详细的错误，但这是很有可能的。通常解决方法是将服务器的 CA 证书导入客户端的信任库。
• 证书是为不同的域颁发的。同样，这会导致更冗长的消息，但我会在此处说明修复方法，以防这是原因。在这种情况下，解决方案是让服务器（它似乎不是您的）使用正确的证书。

由于无法确定底层故障，最好打开 -Djavax.net.debug=all 标志以启用对已建立的 SSL 连接的调试。打开调试后，您可以查明握手中的哪些活动失败了。

更新

根据现在可用的详细信息，问题似乎是由于颁发给服务器的证书与根 CA 之间的证书信任路径不完整所致。大多数情况下，这是因为信任库中没有根CA的证书，导致无法存在证书信任路径的情况；该证书基本上不受客户信任。浏览器可以显示警告，以便用户可以忽略它，但 SSL 客户端（如 HttpsURLConnection 类，或任何 HTTP 客户端库，如 Apache HttpComponents Client ）并非如此。

大多数这些客户端类/库将依赖于 JVM 用于证书验证的信任库。在大多数情况下，这将是 JRE_HOME/lib/security 目录中的 cacerts 文件。如果使用 JVM 系统属性 javax.net.ssl.trustStore 指定了信任存储的位置，那么该路径中的存储通常是客户端库使用的存储。如果您有疑问，请查看您的 Merchant 类，并找出它用于建立连接的类/库。

将服务器的证书颁发 CA 添加到此信任库应该可以解决问题。您可以参考我在有关为此目的 获取工具的相关问题上的回答，但 Java keytool 实用程序 足以满足此目的。

警告：信任库本质上是您信任的所有 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.handshake_failure 中报告 handshake_failure 就足够了。

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

上述步骤之一不会成功，导致 handshake_failure，因为握手通常在此阶段完成（不是真的，但握手的后续阶段通常不会导致握手失败）。您需要弄清楚哪一步失败了，并发布适当的消息作为问题的更新（除非您已经理解该消息，并且知道如何解决它）。

原文由 Vineet Reynolds 发布，翻译遵循 CC BY-SA 3.0 许可协议

Answer 2

握手失败可能是有问题的 TLSv1 协议实现。

在我们的例子中，这有助于 java 7：

 java -Dhttps.protocols=TLSv1.2,TLSv1.1,TLSv1

jvm 将按此顺序进行协商。具有最新更新的服务器将执行 1.2，有问题的服务器将下降到 v1，并且与 java 7 中的类似 v1 一起工作。

原文由 Bela Vizy 发布，翻译遵循 CC BY-SA 3.0 许可协议