收到致命警报：通过 SSLHandshakeException handshake_failure

ssl java ssl-certificate sslhandshakeexception

2022-08-31 07:14:20

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

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

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

//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;

我的商家属性文件：

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，但我有同样的错误，没有更改。

答案 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 目录中的文件。如果信任存储的位置是使用 JVM 系统属性指定的，那么该路径中的存储通常是客户端库使用的存储。如果您有疑问，请查看您的类，并找出它用于建立连接的类/库。cacertsjavax.net.ssl.trustStoreMerchant

将服务器的证书颁发 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，并且所有这些 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就足够了。

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，因为握手通常在此阶段完成（不是真的，但握手的后续阶段通常不会导致握手失败）。您需要确定哪个步骤失败了，并发布相应的消息作为问题的更新（除非您已经理解了该消息，并且您知道该怎么做才能解决它）。

答案 2

握手失败可能是错误的 TLSv1 协议实现。

在我们的例子中，这对java 7有所帮助：

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

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