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 证书模板加密：
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
我的问题是：
- 当服务器提供兼容的密码套件时，为什么基于 Chromium 的浏览器无法协商密码套件？
- 为了允许 Server 2012 R2 使用内部颁发的证书，我需要设置什么？
- 除了将应用程序服务器升级到 2016/2019 之外，还有更好的方法来处理我正在尝试做的事情吗？在这一点上，似乎完全禁用 TLS 并将所有内容放在 LB/反向代理之后可能是一个更好的主意，即使这些是单服务器解决方案。
编辑：我用 Chromium 打开了一个错误，他们已经确认服务器提供的密码套件应该被 Chrome 接受。在我提供了通过 CHROME://Net-Export 捕获的网络日志之后，他们现在正在调查。这可能与旧的Chrome/2012 错误有关。一旦谷歌报告了问题所在，我将再次更新这篇文章。但是，在这一点上，我们这边的配置似乎没有任何问题。
感谢您的关注！
