前言：該篇說明：請見 說明 —— 瀏覽器工作原理與實踐 目錄

在《36 | HTTPS：讓資料傳輸更安全》一文中介紹過：

• HTTPS 使用了對稱和非對稱的混合加密方式，這解決了資料傳輸安全的問題；
• HTTPS 引入了中間機構 CA，CA 通過給伺服器頒發數字證書，解決了瀏覽器對伺服器的信任問題；
• 伺服器向 CA 機構申請證書的流程；
• 瀏覽器驗證伺服器數字證書的流程。

　　不過由於篇幅限制，關於 “瀏覽器如何驗證資料證書” 的這個問題並沒有展開介紹。那麼今天就聊聊這個問題。瞭解了這個問題，可以方便我們把完整的 HTTPS 流程給串起來，無論對於理解 HTTPS 的底層技術還是理解業務都是非常有幫助的。

　　因為本文是 36 講的延伸，所以在分析之前，還是有必要回顧下 數字證書申請流程和瀏覽器驗證證書的流程，最好也去回顧下第 36 講。

數字證書申請流程

　　先來回顧下數字證書的申請流程，比如極客時間向一個 CA 機構申請數字證書，流程是什麼樣的呢？

　　首先極客時間填寫了一張含有自己身份資訊的表單，身份資訊包括了自己公鑰、站點資料、公司資料等資訊，然後將其提交給 CA 機構；CA 機構會稽核表單中內容的真實性；稽核通過後，CA 機構會拿出自己的私鑰，對錶單的內容進行一連串操作，包括了對明文資料進行 Hash 計算得出資訊摘要，利用 CA 的私鑰加密資訊摘要得出數字簽名，最後將數字簽名也寫在表單上，並將其返還給極客時間，這樣就完成了一次數字證書的申請操作。

　　大致流程如下：

 數字證書申請過程

瀏覽器驗證證書的流程

　　現在極客時間的官網有了 CA 機構簽發的數字證書，那接下來就可以將數字證書應用在 HTTPS 中了。

　　在瀏覽器和伺服器建立 HTTPS 連結的過程中，瀏覽器首先會向伺服器請求數字證書，之後瀏覽器要做的第一件事就是驗證數字證書。那麼這裡所說的 “驗證”，它到底是在驗證什麼麼？

　　具體地講，瀏覽器需要驗證證書的有效期、證書是否被 CA 吊銷、證書是否是合法的 CA 機構頒發的。

　　數字證書和身份證一樣也是有時間期限的，所以第一部分就是驗證證書的有效期，這部分比較簡單，因為證書裡面就含有證書的有效期，所以瀏覽器只需要判斷當前時間是否在證書的有效期範圍內即可。

　　有時候有些數字證書被CA 吊銷了，吊銷之後的證書是無法使用的，所以第二部分就是驗證數字證書是否被吊銷了。通常有兩種方式，一種是下載吊銷證書列表 - CRL（Certificate Revocation Lists），第二種是線上驗證方式 - OCSP（Online Certificate Status Protocol），它們各有優缺點，在這裡就不展開介紹了。

　　最後，還要驗證極客時間的數字證書是否是 CA 機構頒發的。驗證的流程非常簡單：

• 首先，瀏覽器利用證書的原始資訊計算出資訊摘要；
• 然後，利用 CA 的公鑰 來解密數字證書中的數字簽名，解密出來的資料也是資訊摘要；
• 最後，判斷這兩個資訊摘要是否相等就可以了。

 　　通過這種方式就驗證了數字證書是否是由 CA 機構所簽發的，不過這種方式又帶來了一個新的疑問：瀏覽器是怎麼獲取到 CA 公鑰的？

瀏覽器是怎麼獲取到 CA 公鑰的？

　　通常，當你部署 HTTP 伺服器的時候，除了部署當前的數字證書之外，還需要部署 CA 機構的數字證書，CA 機構的數字證書包括了 CA 的公鑰，以及 CA 機構的一些基礎資訊。

　　因此，極客時間伺服器就有了兩個數字證書：

• 給極客時間域名的數字證書；
• 給極客時間簽名的 CA 機構的數字證書。

　　然後在建立 HTTPS 連結時，伺服器會將這兩個證書一同傳送給瀏覽器，於是瀏覽器就可以獲取到 CA 的公鑰了。

　　如果有些伺服器沒有部署 CA 的數字證書，那麼瀏覽器還可以通過網路去下載 CA 證書，不過這種方式多了一次證書下載操作，會拖慢首次開啟頁面的請求速度，一般不推薦使用。

　　現在瀏覽器就有了極客時間的證書 和 CA 的證書，完整的驗證流程如下圖：

 CA 證書

 　　有了 CA 的數字證書，也就可以獲取得 CA 的公鑰來驗證極客時間數字證書的可靠性了。

　　解決了獲取 CA 公鑰的問題，新的問題又來了，如果這個證書是一個惡意的 CA 機構頒發的怎麼辦？所以還需要瀏覽器證明這個 CA 機構是個合法的機構。

證明 CA 機構的合法性

　　這裡並沒有一個非常好的方法來證明 CA 的合法性，妥協的方案是，直接在作業系統中內建這些 CA 機構的數字證書，如下圖：

 作業系統內部內建 CA 數字證書

　　我們將所有 CA 機構的數字證書都內建在作業系統中，這樣當需要使用某 CA 機構的公鑰時，只需要依據 CA 機構名稱，就能查詢到對應的數字證書了，然後再從數字證書中取出公鑰。

　　可以看到這裡有一個假設條件，瀏覽器預設信任作業系統內建的證書為合法證書，雖然這種方式不完美，但是卻是最實用的一個。

　　不過這種方式依然存在問題，因為在實際情況下，CA 機構眾多，因此作業系統不可能將每家 CA 的數字證書都內建進作業系統。

數字證書鏈

　　於是人們又想出一個折中的方案，將頒發證書的機構劃分為兩種型別，根 CA（Root CAs）和 中間 CA （Intermediates CAs）， 通常申請者都是向中間 CA 去申請證書的，而 根 CA 作用就是給中間 CA 做認證，一個 根 CA  會認證很多中間的 CA，而這些中間CA 又可以去認證其他的中間 CA。

　　因此，每個根 CA 機構都維護了一個樹狀結構，一個根CA下面包含多箇中間CA，而中間CA又可以包含多箇中間CA。這樣就形成了一個證書鏈，你可以沿著證書鏈從使用者證書追溯到根證書。

　　比如在 Chrome 上開啟極客時間的官網，然後點選位址列前面的能把小鎖，就可以看到 *.geekbang.org 的證書是由中間CA GeoTrust RSA CA2018 頒發的，而中間 CA GeoTrust RSA CA2018 又是由根 CA DigiCert Global Root CA 頒發的，所以這個證書鏈就是：*.geekbang.org  -> GeoTrust RSA CA2018  ->  DigiCert Global Root CA。參考下圖：

 數字證書鏈

　　因此瀏覽器驗證極客時間的證書時，會先驗證 *.geekbang.org 的證書，如果合法，再驗證中間 CA 的證書，如果中間 CA 也是合法的，那麼瀏覽器會繼續驗證這個中間 CA 的根證書。

　　到了這裡依然存在一個問題：瀏覽器怎麼證明根證書是合法的？

如何驗證根證書的合法性

　　其實瀏覽器的判斷策略很簡單，它只是簡單地判斷這個根證書在不在作業系統裡面，如果在，那麼瀏覽器就認為這個根證書是合法的，如果不在，那麼就是非法的。

　　如果某個機構想要成為 根CA，並讓它的根證書內建到作業系統中，那麼這個機構首先要通過 WebTrust 國際安全審計認證。

　　什麼是WebTrust 認證？

　　WebTrust 是由兩大著名註冊會計師協會 AICPA（美國註冊會計師協會）和 CICA（加拿大註冊會計師協會）共同制定的安全審計標準，主要對網際網路服務商的系統及業務運作邏輯安全性、保密性等共計七項內容進行近乎嚴苛的審查和鑑證。只有通過 WebTrust 國際安全審計認證，根證書才能預裝到主流的作業系統，併成為一個可信的認證機構。

　　目前通過 WebTrust 認證的根 CA 有 Comodo、geotrust、rapidssl、symantec、thawte、digicert等。也就是說，這些根CA 機構的根證書都內建在一個大作業系統中，只要能從數字證書鏈往上追溯到這幾個根證書，瀏覽器就會認為使用者的證書是合法的。

總結

　本文主要內容：

　　首先回顧了數字證書的申請流程，接著重點介紹了瀏覽器是如何驗證數字證書的。

　　首先瀏覽器需要 CA 的數字證書才能驗證極客時間的數字證書，接下來需要驗證 CA 證書的合法性，最簡單的方法是將 CA 證書內建在作業系統中。

　　不過 CA  機構非常多，內建每家的 證書到作業系統中是不現實的，於是採用了一個折中的策略，將頒發證書的機構劃分為兩種型別，根 CA（Root CAs）和中間 CA（Intermediates CAs）,通常申請者都是向中間 CA 去申請證書的，而根CA 作用就是給 中間 CA 做認證，一個根 CA 會認證很多中間的 CA，而這些中間 CA 又可以去認證其他的中間 CA 。

　　於是又引出了數字證書鏈，瀏覽器先利用中間 CA 的數字證書來驗證使用者證書，再利用根證書來驗證中間 CA 證書的合法性，最後，瀏覽器會預設相信內建在系統中的根證書。不過要想在作業系統內部內建根證書卻並不容易，這需要通過 WebTrust 認證，這個認證稽核非常嚴格。

　　通過分析這個流程可以發現，瀏覽器預設信任作業系統內建的根證書，這也會帶來一個問題，如果黑客入侵了你的電腦，那麼黑客就有可能往你係統中新增惡意根數字證書，那麼當你訪問黑客站點的時候，瀏覽器甚至有可能會提示該站點是安全的。

　　因此，HTTPS並非是絕對安全的。

思考題

　　複述下瀏覽器是怎麼驗證數字證書的。