如何修复“SSLHandshakeException：收到致命警报：decode_error”？答案

【问题标题】：How to fix 'SSLHandshakeException: Received fatal alert: decode_error'?如何修复“SSLHandshakeException：收到致命警报：decode_error”？
【发布时间】：2019-11-27 22:21:03
【问题描述】：

我们有一个 Java 应用程序可以读取我们客户的公共日历 - 例如来自 google (https://calendar.google.com/calendar/ical/...) 或 icloud (webcal://p58-caldav.icloud.com/published/...)。

直到最近这还有效，但现在 icloud 日历失败并出现以下错误：

javax.net.ssl.SSLHandshakeException: Received fatal alert: decode_error

Google 日历仍然有效。

我们的应用程序通过将 webcal:// 替换为 https:// 并在 URL 上执行 http get 来读取 icloud 日历。

例如。 https://p58-caldav.icloud.com/published/2/MTg3MDA3MjYwMTE4NzAwN1KPAcrTfGuhFJXbGYJ9wEYJFNzP10cp8mw6gSLjUVU_

鉴于在浏览器中点击此 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 (https://webtide.com/openjdk-11-and-tls-1-3-issues/) 中的 TLS1.3 存在问题，但我们已经尝试过使用 java 12 版本但没有成功，所以我认为这不是问题所在。

因此，我们现在必须决定是强制使用 TLS1.2 还是继续寻找其他解决方案。

【问题讨论】：

RFC5246 on TLS 1.2 将错误 decode_error 定义为“由于某些字段超出指定范围或消息长度不正确，无法解码消息。此消息始终是致命的，应该在正确实现之间的通信中永远不会被观察到（除非网络中的消息被破坏）。”所以除了零星问题的故障网络之外，发送的参数之一有问题......（TLS没有提供扩展错误结果的机制，所以没有详细说明）
ClientHello 应提供 SNI 扩展名。这在所有情况下都很好，但可能与您的问题相关，也可能不相关（没有-servername 的主机名上的openssl s_client 似乎有效，因此它可能与您的问题无关）。或者，找到适用于您感兴趣的 URL 的 HTTPS 客户端（如浏览器或 CLI 工具），并将其案例中的 TLS 交换与您的案例进行比较。

标签： java ssl calendar icloud

【解决方案1】：

昨天我在尝试连接到https://apple.com:443 的Java 应用程序时遇到了同样的问题。我发现不同（Docker）操作系统上的不同JDK解决了这个问题。在我的具体情况下，Alpine 上的 OpenJDK 不起作用，但其他 Dockerized OpenJDK（如 adoptopenjdk/openjdk11）运行良好。

【讨论】：

【解决方案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) }

【讨论】：

我试图将加密的附件上传到 Apple 商务聊天 API。我面临收到致命警报：decode_error。我正在使用 java 8。将客户端协议设置为 TLSv1.2 就像一个魅力。