java - 如何修复“SSLHandshakeException:收到致命警报:decode_error”?
问题描述
我们有一个 Java 应用程序可以读取我们客户的公共日历 - 例如来自 google ( https://calendar.google.com/calendar/ical/.. ) 或 icloud (webcal://p58-caldav.icloud.com/发表/...)。
直到最近这才有效,但现在 icloud 日历失败并出现以下错误:
javax.net.ssl.SSLHandshakeException: Received fatal alert: decode_error
谷歌日历仍然有效。
我们的应用程序通过将 webcal:// 交换为 https:// 并在 URL 上执行 http get 来读取 icloud 日历。
鉴于在浏览器中点击此 url 成功返回了有效的 icalendar (ics) 结果,我们首先想到的是,当在 jvm 中运行时,此端点的根 ca 证书不在 jvm 的密钥库中。
我们使用以下命令来获取此端点的证书:
openssl s_client -servername p58-caldav.icloud.com -host p58-caldav.icloud.com -port 443 -prexit -showcerts
然后将链中的两个证书都添加到我们的密钥库中:
keytool -importcert -file apple-ist-ca-2-g1.crt -alias apple-ist-ca-2-g1 -trustcacerts -keystore <java home>/lib/security/cacerts -storepass <pass>
keytool -importcert -file caldav.icloud.com.crt -alias caldav.icloud.com -trustcacerts -keystore <java home>/lib/security/cacerts -storepass <pass>
我们还在测试用例中添加了代码,以验证 jvm 是否正在获取这些证书。
这不起作用,我们得到了同样的错误。
我们正在运行 openjdk 版本“11.0.2”,所以我不认为 SNI 有任何问题或缺少密码(尽管我可能是错的!)
以下非常简单的代码示例重现了该错误:
public class CalReader {
public static void main(String[] args) {
hitAPI("webcal://p58-caldav.icloud.com/published/2/MTg3MDA3MjYwMTE4NzAwN1KPAcrTfGuhFJXbGYJ9wEYJFNzP10cp8mw6gSLjUVU_");
}
private static void hitAPI(final String url) {
String cleaned = url.replace("webcal://", "https://").trim();
InputStream in = null;
try {
URL toUse = new URL(cleaned);
URLConnection conn = toUse.openConnection();
in = conn.getInputStream();
}
catch (Exception e) {
e.printStackTrace();
}
finally {
try {
if (in != null) {
in.close();
}
}
catch (Exception e) {
e.printStackTrace();
}
}
}
}
添加 ssl 调试 (-Djavax.net.debug=ssl:handshake:verbose) 不会(在我看来)提供任何相关信息。但是,我承认我不是 ssl 专家。
javax.net.ssl|DEBUG|01|main|2019-07-18 11:51:53.042 AEST|ClientHello.java:651|Produced ClientHello handshake message (
"ClientHello": {
"client version" : "TLSv1.2",
"random" : "BC DF 54 80 F2 0B 9A F9 42 17 4A FF B9 B5 65 22 C4 9E 19 63 0A 88 81 1F 84 2A 74 2D 40 40 F2 F0",
"session id" : "A9 21 0D FE 9B 8E 9F B8 53 17 60 09 D4 B2 C8 EE BE FD 7F AC 93 57 12 4B 47 BA FF A9 7A DF C4 EF",
"cipher suites" : "[TLS_AES_128_GCM_SHA256(0x1301), TLS_AES_256_GCM_SHA384(0x1302), TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384(0xC02C), TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B), TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xC030), TLS_RSA_WITH_AES_256_GCM_SHA384(0x009D), TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384(0xC02E), TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384(0xC032), TLS_DHE_RSA_WITH_AES_256_GCM_SHA384(0x009F), TLS_DHE_DSS_WITH_AES_256_GCM_SHA384(0x00A3), TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F), TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C), TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256(0xC02D), TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256(0xC031), TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E), TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384(0xC024), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384(0xC028), TLS_RSA_WITH_AES_256_CBC_SHA256(0x003D), TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384(0xC026), TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384(0xC02A), TLS_DHE_RSA_WITH_AES_256_CBC_SHA256(0x006B), TLS_DHE_DSS_WITH_AES_256_CBC_SHA256(0x006A), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA(0xC00A), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(0xC014), TLS_RSA_WITH_AES_256_CBC_SHA(0x0035), TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA(0xC005), TLS_ECDH_RSA_WITH_AES_256_CBC_SHA(0xC00F), TLS_DHE_RSA_WITH_AES_256_CBC_SHA(0x0039), TLS_DHE_DSS_WITH_AES_256_CBC_SHA(0x0038), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256(0xC025), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067), TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(0xC009), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xC013), TLS_RSA_WITH_AES_128_CBC_SHA(0x002F), TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(0xC004), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(0xC00E), TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033), TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032)]",
"compression methods" : "00",
"extensions" : [
]
}
)
javax.net.ssl|DEBUG|01|main|2019-07-18 11:51:53.046 AEST|Alert.java:232|Received alert message (
"Alert": {
"level" : "fatal",
"description": "decode_error"
}
)
我们刚刚在 java 8 环境中进行了尝试,它按预期工作。作为一个快速测试,我们将我们的 java 8 环境 cacerts 复制到我们的 java 11 环境,但是它仍然无法正常工作。java 8 环境中还有什么可以让它工作的?
很难确定,但似乎这发生在过去 2-4 周左右。我们有证据表明在 6 月 24 日成功读取了 icloud 日历,并且我们从 7 月 4 日开始看到上述错误。
我们已经尝试了多个 icloud 日历并且每个都得到相同的结果,所以它似乎与日历本身无关。
更新
我们强制使用 TLS1.2 并且它有效。对于上面的例子:
java -Dhttps.protocols=TLSv1.2 CalReader
这就引出了一个问题,Apple 端点是否存在 TLS1.3 问题?或者是别的什么?
我们确实找到了一篇文章,指出 java 11 中的 TLS1.3 存在问题(https://webtide.com/openjdk-11-and-tls-1-3-issues/),但我们已经尝试过使用 java 12版本没有成功,所以我认为这不是问题。
因此,我们现在必须决定是强制使用 TLS1.2 还是继续寻找其他解决方案。
解决方案
我Received fatal alert: decode_error
在连接苹果云网址时遇到了问题。我可以通过将协议明确设置为TLS 1.2
.
例如:在kotlin
更新您spring RestTemplate
的如下,
fun restTemplateWithTLS12(): RestTemplate {
val requestFactory = HttpComponentsClientHttpRequestFactory()
val sslContext = SSLContexts.custom().setProtocol("TLSv1.2").build()
val clientBuilder =
HttpClients.custom().setSSLSocketFactory(SSLConnectionSocketFactory(sslContext))
requestFactory.httpClient = clientBuilder.build()
return RestTemplate(requestFactory)
}
推荐阅读
- linux - 如何将所有现有文件从远程 sftp 服务器传输到本地目录并创建一个包含这些文件列表的 .txt 文件?
- sql - Oracle根据一列将行转换为动态列
- postgresql - 将本地 postgres 数据库复制到 AWS RDS 的最佳方法是什么?
- adobe-indesign - 通过脚本为标准 InDesign 面板提供了哪些方法和属性以供使用?
- excel-formula - 获取 Excel 公式中使用的单元格数
- hpc - Snakemake:将多个作业聚集在一起
- database - 如何自动将收到的 gmail pdf 文件保存到数据库中?
- python - 如何修复'int对象不可迭代'
- c - scanf_s 读取字符我在做什么错?
- angular - 无法运行 Spring Boot 多模块 War 文件