gpt4 book ai didi

java - 收到致命警报:SSLHandshakeException中的handshake_failure

转载 作者:行者123 更新时间:2023-12-02 01:19:43 28 4
gpt4 key购买 nike

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

最佳答案

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


客户端和服务器使用的密码套件不兼容。这将要求客户端使用(或启用)服务器支持的密码套件。
使用了不兼容的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添加到此信任存储区应该可以解决此问题。您可以为此目的参考我的answer on a related question on getting tools,但是Java keytool utility足以满足此目的。

警告:信任库实质上是您信任的所有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会声明。

2. 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


上述步骤之一将不会成功,从而导致handhake_failure,因为握手通常在此阶段完成(不是真的,但是握手的后续阶段通常不会导致握手失败)。您需要确定哪个步骤失败了,并发布适当的消息作为问题的更新(除非您已经理解了该消息,并且知道如何解决该问题)。

关于java - 收到致命警报:SSLHandshakeException中的handshake_failure,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/57632657/

28 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com