主页 / server / 问题 / 1037018
Accepted
RobbieCrash
Asked: 2020-10-09 23:02:13 +0800 CST

Chromium 浏览器 TLS1.2 在 Server 2012 R2 上使用 ADCS 颁发的证书失败

  • 772

tl;dr：使用 AD CS 颁发的证书时，Server 2012 R2 和基于 Chromium 的浏览器之间的 TLS 1.2 失败。在 Server 2016+ 和 2012 R2 上使用 Firefox/IE/Cygwin-curl 运行良好。

我们有几个内部 Server 2012 R2 Web 服务器，我们正试图将它们从公开颁发的证书转移到由我们的 AD 集成 CA 颁发的证书上，并消除不太安全的加密设置，包括 CBC MAC。Server 2012 R2 不支持 GCM 的 ECDHE_RSA，这意味着我们正在尝试使用基于 ECDH 的证书。但是，当我们允许使用 CBC-MAC 的密码套件时，我们遇到了类似的问题，例如 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 以及从同一 CA 颁发的 RSA 证书。使用 GlobalSign 颁发的公共通配符证书，我们能够连接所有浏览器。

企业 CA 和脱机根 CA 都是受信任的，我们已经验证它工作正常。使用颁发给 2016 和 2019 服务器的多个不同模板的证书在所有浏览器上都可以正常工作。基于 ECDH 和 RSA 的模板在 2016+ 上同样适用。

ECDH 证书模板加密： ECDH 证书模板加密设置。

RSA 证书模板加密： RSA 证书模板加密设置。

2012 R2 服务器上的 RSA 和 ECDH 证书都被 Firefox security.enterprise_roots.enabled、pre-Chromium Edge、IE 和 Cygwincurl和wget. 我已经确认我们在注册表中使用了现代密码，使用IISCrypto重新设置它们，并验证了服务器使用 OpenSSL 和 nmap 提供了兼容的可用密码。同样，我已经确认客户端实际上能够使用这些密码进行连接。

Firefox 显示它正在与 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 连接，根据Qualys，我们正在使用的 Chrome 版本支持它。

与 ECDH

PORT    STATE SERVICE
443/tcp open  https
| ciphers:
|   TLSv1.1:
|     ciphers:
|       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|     compressors:
|       NULL
|     cipher preference: server
|_  least strength: A

每次我们尝试与 Chrome 连接时，都会记录一对事件 36874/36888，说明客户端上没有支持的密码套件。

我们在使用企业 CA 颁发的证书时遇到问题的密码套件列表，其中大部分仅用于测试（警告已被剪断）：

PORT    STATE SERVICE
443/tcp open  https
| ciphers:
|   SSLv3:
|     ciphers:
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|   TLSv1.0:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.1:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 1024) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1024) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|_  least strength: C

我的问题是：

  1. 当服务器提供兼容的密码套件时，为什么基于 Chromium 的浏览器无法协商密码套件？
  2. 为了允许 Server 2012 R2 使用内部颁发的证书，我需要设置什么？
  3. 除了将应用程序服务器升级到 2016/2019 之外，还有更好的方法来处理我正在尝试做的事情吗？在这一点上，似乎完全禁用 TLS 并将所有内容放在 LB/反向代理之后可能是一个更好的主意，即使这些是单服务器解决方案。

编辑：我用 Chromium 打开了一个错误，他们已经确认服务器提供的密码套件应该被 Chrome 接受。在我提供了通过 CHROME://Net-Export 捕获的网络日志之后，他们现在正在调查。这可能与旧的Chrome/2012 错误有关。一旦谷歌报告了问题所在，我将再次更新这篇文章。但是，在这一点上，我们这边的配置似乎没有任何问题。

感谢您的关注！

ssl google-chrome windows-server-2012-r2 microsoft-edge iis-8

2 个回答

  1. 请确保您的证书签名请求 (CSR) 未请求仅对签名有效的证书，而不是对签名和加密有效的证书。如果 CSR 要求仅对签名有效的证书，并且您的 CA 具有允许加密的策略，即使请求仅在签名时也允许加密，那么您可能会看到这个问题......有时。显然，仅请求签名的证书在用于加密时根本不应该工作，但是如果您的 CA 覆盖请求以允许加密，这将创建加密工作的情况，但仅在客户端支持几个特定的​​情况下协议套件。识别导致此问题的证书很复杂。

    尝试使用wireshark 捕获W2012 R2 和Chrome 之间的流量。如果协议协商是问题，您将在客户端建议密码套件列表后立即看到服务器重置连接。来自客户端的此数据包将具有“客户端问候”的信息，紧随其后的是来自服务器的 TCP RST（重置）。如果您深入了解“客户问候”数据包的详细信息，您将能够看到客户提出的套件。

    要解决此问题，您需要确保订购的证书用于正确目的（https://docs.microsoft.com/en-us/archive/blogs/pki/how-to-create-a-web-服务器-ssl-证书-手动）。确保您的证书请求具有正确的参数（包括证书使用情况）至关重要。如果您将 Windows PKI 与 AD 集成模板一起使用，您可以根据需要在模板中“硬编码”它。

    • 1
  2. Best Answer

    Google 已确认这是 Chromium 处理 ClientHello 的方式、IIS 在 2012 年如何处理事情以及我们的根 CA 的根证书签名中使用的算法的问题。

    2012r2 上的 IIS 使用 ClientHello 对链中的每个证书进行检查。Chrome 不宣传，但支持根 CA 的 SHA-512、ECDH 证书。因此，当 IIS 对整个证书链执行检查时，它会看到 Chrome 提供对来自网络服务器（来自我们的中间 CA）的密码的支持，但它不提供对 P-521 ECDH 的支持（诚然是矫枉过正）曲线，以便 IIS 重置连接。Chrome 并未宣传对此的支持以处理 TLS1.2/1.3 字段映射混乱中的边缘情况。

    我对 Chromium 错误报告的建议是替换根 CA，或者升级到不再是问题的 2016/2019。

    • 1

相关问题