☰

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

tag-icon • tag-icon apache-2.4 ssl-certificate openssl ssl-certificate-errors
Chrome 116/117 的 HTTPS 兼容性问题 ERR_SSL_PROTOCOL_ERROR

ERR_SSL_PROTOCOL_ERROR由于某种原因，我的网站从两天前开始出现错误。

测试的浏览器

  • Windows Chrome 117.0.5938.132：ERR_SSL_PROTOCOL_ERROR
  • Android Chrome 117.0.5938.61：ERR_SSL_PROTOCOL_ERROR
  • Windows Firefox 118.0.1：正常
  • Edge 117.0.2045.47 ：确定
  • 手头没有其他浏览器，但客户只抱怨 Chrome

Web 服务器配置

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

  • 证书有效（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 实验室，我看到的唯一巨大的抱怨是，This server supports weak Diffie-Hellman (DH) key exchange parameters. Grade capped to B.我不知道该怎么办，也不确定它是否是罪魁祸首。

答案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-1，尽管客户端和服务器都更喜欢 SHA-2。虽然所有带有该漏洞的 OpenSSL 版本早已停产，但仍有少数服务器在运行它。

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

希望有帮助！

答案2

我的 Chrome/Windows (现在！) 是同一版本，并且可重现；wireshark 中唯一可能的情况是，在正确协商 1.2 后 (Chrome 提供 1.3 但接受 1.2)，服务器使用 (RSAv1.5+)SHA1 对 ServerKX 进行签名，Chrome 发送 alert47 illegal_parameter。SHA1 协议签名在 1.3 中是被禁止的，但据我所知，在 1.2 中才被弃用 (rfc9155)。

果然，在 chrome://flags 中是#使用 sha1 服务器握手; 如果我启用该功能并重新启动您的网站现在可以正常工作了。（当然，现在这是一个标记，意味着它可能很快就会被彻底删除。）

您说得对，旧式 DHE 又名 FFDHE 参数不是这里的问题，因为 Chrome 更喜欢（因此服务器选择）ECDHE（带有 P-256）而不是 FFDHE（包含该套件）。如果您认为很可能有人会使用不支持（并且更喜欢）ECDHE 的浏览器或其他客户端访问您的网站，那么修复它们可能是个不错的选择。如果不行，您可以通过将所有 (FF)DHE 套件添加!DH到您的 中删除，让 SSLLabs 更满意SSLCipherSuite。另一方面，您可以删除!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4- 除了 PSK（在 Apache 中永远无法选择）之外，没有添加任何套件，因此无需删除它们。（要让 SSLLabs 完全满意，您必须删除所有非 AEAD 套件，这实际上意味着非 GCM，但这会阻止相当大一部分潜在客户；是否做出这种权衡取决于您。）

答案3

谷歌已开始推出一项更新，在协商过程中拒绝 SHA1 服务器签名，即使您的证书使用 SHA256 签名。

看https://groups.google.com/a/chromium.org/g/blink-dev/c/ZdpqIOKTHeM

确实，临时解决方案是在客户端将标志 #use-sha1-server-handshakes 设置为 Enabled 以使其工作。但最终解决方案是确保有问题的服务器使用的是升级版的 OpenSSL 库，该库使用 SHA256 签名而不是 SHA1 签名。

答案4

（已解决）我遇到了同样的问题。我将 openssl 从 1.0.1 升级到1.1.1周。

然后重新启动 nginx（可能没有必要）。

它解决了这个问题

升级指南

相关内容