和第三方对接,遇到点问题,求大佬解惑

[Evilk]

现在的情况:

1.Java 那边,通知我们后端(PHP)处理结果,但他们那边一直报错

java.lang.RuntimeException: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

2.尝试过的方法:

(1).他们在他们的服务器上,curl 我们的 URL,成功

(2).用 postman,访问我们的 URL,成功

(3).直接通过浏览器访问我们的 URL,成功

之前怀疑是 TLS 版本问题 后来检查了我们的服务器,同时支持 TLS-1.2 & TLS-1.3 & HTTP/2

现在的问题:

对方找不到原因,让我们检查 问题是,其他方式都能成功, 只是他们通过 Java 程序,直接通知我们,就报错

有人遇到过这种情况吗?

[tankren]

回复：找不到原因，自己检查

[Evilk]

@tankren 关键其他方式都能成功,就他们程序报错,他们找不到原因.感觉无解.

[jfjiefan]

之前遇到过，都是 java 端支持的协议或加密过低导致。
要么 java 升级版本
要么 nginx 这边支持不再安全的协议或加密算法

[entertainyou]

应该是对方用的 java 版本太旧，bundle 的 CA 证书太老.

https://www.ssllabs.com/ 这里可以测试 ssl 证书的兼容性. 你也可以问下对方用的 jre 版本，然后用相同的 jre 版本写个测试代码访问看能不能复现.

[Evilk]

@jfjiefan 我不太懂 Java,应该如何跟对方阐述清楚?

[Evilk]

@entertainyou 对方只是说,他们的 jdk 版本是 1.8

[MoYi123]

让他们做个 docker 镜像发过来。

[xuanbg]

用 http 协议看看是不是就不报错了，是的话就是你这边的证书有问题或者他们那边的 ssl 库有问题。如果他们用 https 连别家接口正常，那基本就是你家证书的问题了。

[dilu]

你用 php 写个脚本去请求，用 strace 看一下系统调用

方便的话贴一下 strace 的调用结果 大家一起探讨一下

[qwerthhusn]

对方不是 jdk1.8，如果是 8 以下，默认只会用 1.1 1.0 版本

如果用的是 jdk11 的早期版本，TLS1.3 的 java 实现是有 BUG 的，要么更新到 jdk11 新的版本，要么通过配置让客户端自行禁用 1.3

[lscho]

查个毛查，给自己找事干呢，1 、2 、3 的三张截图甩给他们让他们自己查。。

[Evilk]

问题是,我们服务经常和第三方通讯,从来没有因为 SSL 的问题报错
他们也说,他们和其他家通讯,也没有报错,就跟我们通讯报错

[Evilk]

@xuanbg 问题是,我们服务经常和第三方通讯,从来没有因为 SSL 的问题报错
他们也说,他们和其他家通讯,也没有报错,就跟我们通讯报错

[NjcyNzMzNDQ3]

这不就是甩锅吗。。见的挺多了，很无奈的

[Evilk]

@dilu 你的意思是,去请求他们 Java 的某个接口吗?

[Evilk]

@qwerthhusn 你的意思是,对方不是用的 jdk1.8? 所以他们 Java 程序只支持 TLS 1.1 1.0 吗?
我应该如何阐述清楚,让他们检查他们 Java 的 TLS 版本?

[Evilk]

@lscho 1-3 方法,我们双方都清楚,但他们说,他们和别家通讯没问题,就和我们通讯有问题
我们也是如此,现在就僵持在这里了,烦死了

[LinJunzhu]

应该是你们的 SSL 证书缺失中间证书的问题， Java 、Android WebView 不支持自动去找中间证书，Mac 、Window 、iOS 都支持。

所以只会在 Java Api 调用 / Android WebView 访问 时会发生

[LinJunzhu]

解决方式是： 把你们的 SSL 正式跟中间证书合并， 有在线合并证书的网站，搜下就有

[index90]

让他们 Java 程序发起请求，你这边抓 handshake 包看看啊

[Evilk]

这是我们服务器 curl 对方的返回:


* About to connect() to xxx port 443 (#0)
* Trying xxx...
* Connected to xxx (xxx) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* Server certificate:
* subject: O=Internet Widgits Pty Ltd,ST=Some-State,C=AU
* start date: 7 月 22 06:02:24 2016 GMT
* expire date: 8 月 21 06:02:24 2016 GMT
* common name: (nil)
* issuer: O=Internet Widgits Pty Ltd,ST=Some-State,C=AU
* NSS error -8181 (SEC_ERROR_EXPIRED_CERTIFICATE)
* Peer's Certificate has expired.
* Closing connection 0
curl: (60) Peer's Certificate has expired.
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.


这代表什么意思?

[dilu]

@Evilk #15 抱歉看错了 原来是对方访问你们报错啊

那让对方用 strace 看一下系统调用

[qq1340691923]

都统一下，换成 java

[Evilk]

现在对方服软了
在让检查他们服务器的根证书,怀疑是过期或者无效
所以 HTTPS 握手失败

[qwerthhusn]

@Evilk 不是 1.8，可能是高于 1.8，那肯定支持 TLS1.2 的；如果是以下的话，jdk7 支持 1.2 但是需要手动在程序配置中开启，jdk6 就很老肯定不支持 1.2 了

还有一种方式，抓包放 wireshark 看，Client Hello 报文，很容易就看出来客户端支持的版本

除了版本问题，还有可能是 CA 不被认的问题，楼上很多都给了检测方式。。。

[sampeng]

现在程序员都不认识英文么…
SEC_ERROR_EXPIRED_CERTIFICATE)
* Peer's Certificate has expired.

[sampeng]

这还用怀疑？证书有效时间是 2016 年

[Evilk]

@qwerthhusn 现在应该不是 TLS 版本问题
应该是我们服务器要求的

Cipher : ECDHE-ECDSA-CHACHA20-POLY1305

对方 Java 不支持,目前对方还在找原因
哎

[Evilk]

而且对方的证书,是自己签的,不是通过 CA 来的
访问我们的时候,我们认为证书无效,所以拒绝了对方的 HTTPS 握手请求

[qwerthhusn]

@Evilk 为啥会要求 CHACHA20-POLY1305 这套？？？
以前 AES 在移动设备上比较慢，google 弄出来一个 CHACHA20，比 AES 快一点
后来 ARM 指令集有了 AES-NI，即硬件计算 AES，现在主流的又变回 AES 了
而且一般 TLS Server 应该设置成同时支持 AES 和 CHACHA 的。。

对方的证书？？ Server 要求客户端 SSL 认证？不要求的话，客户端传什么证书。。。。。要求的话，是服务端指定验证客户端证书的 CA 的。