Chrome 116/117 ERR_SSL_PROTOCOL_ERROR 的 HTTPS 兼容性问题

Question

ERR_SSL_PROTOCOL_ERROR由于某种原因，我的网站从 2 天起就出现错误。

已测试浏览器

• Windows Chrome 117.0.5938.132：ERR_SSL_PROTOCOL_ERROR
• 安卓 Chrome 117.0.5938.61：ERR_SSL_PROTOCOL_ERROR
• Windows 火狐 118.0.1：好的
• 边缘 117.0.2045.47：好的
• 手头没有其他浏览器，但客户只抱怨 Chrome

网络服务器配置

是的，我的网络服务器已经过时，计划在几个月内迁移。

• 证书有效（Sectigo）
• Apache HTTPd 2.4.3
• OpenSSL 1.0.1m

无法运行的网站是https://specto.ca

Apache HTTPd 配置原文

测试前的配置

[...]
<IfModule ssl_module>
    SSLRandomSeed startup builtin
    SSLRandomSeed connect builtin

    SSLStrictSNIVHostCheck off
</IfModule>
[...]
<VirtualHost 69.70.187.100:443>
    [...]
    ServerAlias specto.ca
    ServerAlias www.specto.ca
    [...]
    SSLEngine on
    SSLCertificateFile /home/.../ssl.crt
    SSLCertificateKeyFile /home/.../ssl.key
    SSLCACertificateFile /home/.../chain.crt
</VirtualHost>

Apache HTTPd 配置正在运行

我测试后的配置

[...]
<IfModule ssl_module>
    SSLRandomSeed startup builtin
    SSLRandomSeed connect builtin

    SSLStrictSNIVHostCheck on

    SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite          ECDHE-RSA-WITH-AES-128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
    SSLHonorCipherOrder     off
</IfModule>
[...]
<VirtualHost 69.70.187.100:443>
    [...]
    ServerAlias specto.ca
    ServerAlias www.specto.ca
    [...]
    SSLEngine on
    SSLCertificateFile /home/.../ssl.crt
    SSLCertificateKeyFile /home/.../ssl.key
    SSLCACertificateFile /home/.../chain.crt
</VirtualHost>

两种配置都有相同的问题，我只是假设协商正在 TLS v1.1 上尝试，这就是拒绝的原因。

我已经在Qualys SSL Labs上进行了测试，我看到的唯一巨大的抱怨是This server supports weak Diffie-Hellman (DH) key exchange parameters. Grade capped to B.我不确定该怎么办，并且不确定它是罪魁祸首。

Answer 1

如果您刚刚开始看到此情况，这可能是由于不再支持 SHA-1 服务器签名。这不是由 CA 生成的证书中的签名，而是在 TLS 1.2 握手期间生成的签名，由服务器软件生成。（有关详细信息，请参阅Chrome 状态和RFC 9155。）

如果切换chrome://flags/#use-sha1-server-handshakes到“启用”（而不是“默认”或“禁用”）使问题消失，则可能就是这个原因。

通常，这是 TLS 服务器软件的错误，而不是配置问题，因为 TLS 1.2 从第一天起就支持 SHA-2，并且很少有人更改默认的签名算法首选项。

我们看到的最常见的问题是，非常旧的 OpenSSL 版本存在一些 错误，导致它在 SNI 协商过程中弄乱其内部状态，并忘记它正在签署哪种签名算法。然后，即使客户端和服务器都更喜欢 SHA-2，它最终也会选择 SHA-1。尽管所有存在该 bug 的 OpenSSL 版本早已停产，但仍有少数服务器在运行它。

在这种情况下，解决方法是您应该将 OpenSSL 更新到更新版本。我相信 1.0.2m 是修复了错误的最低版本，但当然，建议更新到受支持的版本。（1.0.2 系列已于 2019 年停产。）如果您从 Linux 发行版获得 OpenSSL，更新它可能是最简单的选择。

希望有帮助！