Java 收到致命警报：通过SSLHandshakeException的handshake_failure

Question

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

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

我的Action类中的My Method将数据发送到服务器

//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，但我遇到了相同的错误，没有任何更改。

Answer 1

握手失败可能是由于多种原因引起的：

• 客户端和服务器使用的密码套件不兼容。这将要求客户端使用（或启用）服务器支持的密码套件。
• 正在使用不兼容的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 : 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都用于不同的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. ClientHello

初始化连接时，将报告一系列条目。客户端在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 }
***

请注意使用的密码套件。这可能必须与商人.properties文件中的条目一致，因为银行的图书馆可能采用相同的约定。如果使用的约定不同，则无需担心，因为如果密码套件不兼容，ServerHello会声明。

1. ServerHello

服务器以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，因为握手通常在此阶段完成（不是真的，但是握手的后续阶段通常不会导致握手失败）。你需要找出失败的步骤，然后发布适当的消息作为问题的更新（除非你已经理解了该消息，并且知道该怎么做）。

分享改善这个答案