為什麼 Chrome 會說你的 SHA-2 證書鏈是「肯定不安全的」

假如你已經完全配好了你的 SSL：使用了強加密演算法、禁用了廢棄的協議，而且你提供了 100% SHA-2 的證書鏈。SSL Labs 給了你一個 A+ 評分，shaaaaaaaaaaaaa.com 也沒發現你使用了 SHA-1。但是，有些情況下，當你訪問你的網站時，Chrome 仍舊會在 URL 欄處顯示一個紅叉，並且說你的網站提供了 SHA-1 證書，是「 肯定不安全的 （ affirmatively insecure ） 」 的：

這可能嗎？不幸的是，有可能。你的伺服器所發送的證書也許並不是你的瀏覽器所使用的。在遷移到 SHA-2 的過程中不應該是這樣的，但是由於某些 CA 糟糕的做法和用戶使用了老舊的軟體，有時候會出現這樣的問題。具體聽我一一道來。

背景知識：證書鏈如何工作

一個 SSL 證書必須被 證書授權中心 （ certificate authority，CA ） 簽名才是可信的。在最簡單的情況下，網站的證書（ 終端證書 （ end-entity certificate ） ）是由瀏覽器所信任的 CA 的（ 根證書 （ root certificate ） ）直接簽名的。

簡單 PKI: 終端證書由根證書直接簽名

瀏覽器校驗直接由根證書籤名的證書很簡單：瀏覽器在它的根證書庫裡面查找終端證書的簽發者，如果找到，就使用該根證書的公鑰來校驗終端證書的簽名。

然而，終端證書很少會由根證書進行簽名。相反的，終端證書是由一個「 中間證書 （ intermediate certificate ） 」（有時候也稱之為 下級 CA （ subordinate CA ） ）進行簽名的，而中間證書則由根證書進行簽名。

典型的 PKI 是使用一個中間證書

校驗一個由中間證書籤名的證書是困難的。瀏覽器不能簡單地在它的根證書庫中找到簽發者，因為該證書並不是由根證書籤名的。相反，瀏覽器需要找到簽名該證書的中間證書，需要的話還得迭代這個過程（中間證書也許是由其它的中間證書籤名的），直到沿著這個證書鏈找到根證書。而事實上更複雜，因為也許從終端證書到根證書有幾種可能的鏈路。

讓瀏覽器找到中間證書鏈的最簡單的辦法是，讓伺服器告訴它。這就是為什麼當你部署一個 SSL 證書時，不僅僅需要你自己的證書，還需要中間證書。不過，瀏覽器通常會緩存中間證書，也許會使用一個緩存的證書而不是使用由你的伺服器提供的證書。這就是為什麼在你全部使用了 SHA-2 之後， Chrome 也許還會顯示一個紅叉的原因：它並沒有使用你的證書鏈上提供的證書，而是使用了其所緩存的 SHA-1 的證書鏈。

理論上，這是可以避免的，如果 CA 可以正確操作、用戶也運行最新的軟體的話。不幸的是，現實並不總是這樣，個別情況下已知導致這個問題的原因有兩個。

（注意：澄清一下，生成證書鏈的並不是 Chrome ，而是 Chrome 交由操作系統的加密庫構建證書鏈。加密庫在 Windows 上是 CryptoAPI，Linux 上是 NSS。）

問題一：將 SHA-1 中間證書用 SHA-2 重用

當 CA 遷移到 SHA-2 時，它可以通過對已有的公鑰用 SHA-2 重新簽名，從而重用已有的中間證書，或者也可以生成一個帶有新的公鑰和 主題名 （ subject name ） 的新中間證書。

兩種新的 SHA-2 簽名方式

第一種方式是錯誤的。雖然 CA 可以用已有的中間證書使用 SHA-2 重新簽名，但是瀏覽器也許會緩存著帶有舊的 SHA-1 簽名的中間證書。如上面解釋的，瀏覽器可以忽略由伺服器提供的鏈證書，即便伺服器發送了帶有新的 SHA-2 簽名的中間證書，客戶端依然會使用其所緩存的 SHA-1 中間證書來構建證書鏈。CryptoAPI 就是這樣的。

伺服器發送了 SHA-2 證書，瀏覽器使用了緩存的 SHA-1 證書

而第二個辦法就避免了緩存證書鏈的問題。因為 CA 生成了一個新的中間證書，有新的名字和公鑰，瀏覽器不可能有用 SHA-1 簽名的舊版本。這就是為什麼 Ballot 118 在 CA/Browser Forum 這樣說：

SHA-2 下級證書絕不應該鏈到 SHA-1 的 CA 下級證書上。

不幸的是，有些 CA 根本沒在意這個忠告，比如某個 CA ，StartCom，仍然使用 SHA-1 中間證書籤發 SHA-2 終端證書。雖然他們提供了一個 SHA-2 簽名的中間證書，但是如果瀏覽器已經有一個緩存的 SHA-1 版本時就會有問題。

幸運的是，SSLMate 的兩個 CA 都正確地從新的 SHA-2 中間證書籤發證書，所以，SSLMate 的客戶不需要擔心這個。

問題二：過期的 NSS 和交叉簽名的根證書

有時候根證書自身也由其它的根證書籤名，通常這稱之為 交叉簽名 （ cross-signing ） 。這提供了一個抵達可信根證書的另外一條路徑，交叉簽名可以讓一個不在你的瀏覽器的可信證書庫中的新根證書也可以工作。當瀏覽器開始信任一個根證書時，交叉簽名的證書就不再需要了。然而，和中間證書一樣，交叉簽名的證書也是可以緩存的，而在 NSS 中一個 bug 會導致 Linux 上的 Chrome 使用緩存的交叉簽名的根證書，即使有更短和更新的證書鏈存在。如果這個緩存的交叉簽名證書正好使用 SHA-1，Chrome 就會使用這個有問題的證書鏈並顯示一個紅叉，而不管你的伺服器是否發送了全都使用 SHA-2 的證書鏈。

NSS 使用緩存的交叉簽名證書構建證書鏈

這個 bug 在 NSS 3.17.4 中修復，發佈於1/28。不幸的是，Debian 更新 NSS 軟體包非常緩慢。這個 bug 在2014/12/30 就提交到了 Debian 的 bug tracker 上了，但是直到 5/13 都沒在 Debian Unstable 中修復。同時，Debian Stable （Jessie）繼續用著 NSS 3.17.2 。Debian 安全團隊排除了會通過安全更新修復它，而且看起來包維護者也不像是會快速響應將這個修復加入到即將發布（本文寫作時）的 Debian Stable 中。Ubuntu 則不同，將此作為安全問題，在 2/19 給其所有發行版發布了更新包。

不幸的是，CA 不能為使用過期 NSS 的用戶做些什麼。直到 Debian 為其穩定發行版發布更新的 NSS 包之前，Debian 上的 Chrome 用戶會一直看到許多這樣的紅叉：

或者，如果證書在 2016 年失效的話是這樣：

更新：由 SSLMate 的 Andrew Ayer 提供的 NSS 更新包，放到了 2015/9/5 發布的 Debian Jessie 8.2 中。

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive