Chromium 瀏覽器 TLS1.2 在 Server 2012 R2 上使用 ADCS 頒發的證書失敗

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

我的問題是：

1. 當伺服器提供兼容的密碼套件時，為什麼基於 Chromium 的瀏覽器無法協商密碼套件？
2. 為了允許 Server 2012 R2 使用內部頒發的證書，我需要設置什麼？
3. 除了將應用程序伺服器升級到 2016/2019 之外，還有更好的方法來處理我正在嘗試做的事情嗎？在這一點上，似乎完全禁用 TLS 並將所有內容放在 LB/反向代理之後可能是一個更好的主意，即使這些是單伺服器解決方案。

**編輯：**我用 Chromium 打開了一個錯誤，他們已經確認伺服器提供的密碼套件應該被 Chrome 接受。在我提供了通過 CHROME://Net-Export 擷取的網路日誌之後，他們現在正在調查。這可能與舊的Chrome/2012 錯誤有關。一旦Google報告了問題所在，我將再次更新這篇文章。但是，在這一點上，我們這邊的配置似乎沒有任何問題。

感謝您的關注！

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。

請確保您的證書籤名請求 (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 集成模板一起使用，您可以根據需要在模板中“硬編碼”它。

引用自：https://serverfault.com/questions/1037018