瀏覽器如何驗證HTTPS證書的合法性？

一 前提：

1. 證書存在的目的就是避免中間人攻擊，避免發生經典的傳令兵問題。
2. 證書都是由CA組織下認可的根證書Root簽發的（其中有兩種形式，第一種是該組織有一個Root，每一家的Root Ca都需要其簽名，該方案基於利益考量幾乎沒人采用，而是第二種方案，每家都有自己的Root CA 可以自簽或者互相簽名)。這個組織很難進，目前幾乎完全由歐美控制,每年都有輪值主席負責該年CA組織工作，主要涉及到新的RFC審核和修改，新的CA申請和已有CA日志審核以及提出新的CA方案等。其他不通過該組織認證的證書簽發者都是不安全的，此外該組織會對每年每個CA簽發的證書進行審核。因此可以保證正常途徑簽發的證書根是絕對可信的。所有改組織通過的CA會強迫瀏覽器和系統安裝(常見的廠商有VeriSign, Microsoft, Oracle和Molliza 這也是強制力的來源)
3. 證書分為DV(Digital Verification)，OV(Organization Verification)和EV(Extended Verification)，其中EV證書最貴，可以在瀏覽器中看到綠色的就是EV證書。證書從申請到批准要走很久的流程，需要提供很多的公司認證信息和個人信息，否則是不會通過的。因此可以保證簽發的證書內容是可信的。
4. 證書是需要預裝的，特別是根證書。IE和Chrome是通過內置在Windows系統中的TrustStore來管理根證書（當然自己也可以手動導入自簽證書，瀏覽不會認可的因為有OCSP和CRL--之后細講）；而Firefox則是內置在自己的瀏覽中。
5. 綜上，通俗的來說一個CA如果要商業化，要做以下幾步：申請加入CA組織，然后向Microsoft提申請加入TrustStore(通過Windows自我更新或者通過其他證書導入時加入）和Mozilla組織申請加入Firefox TrustStore。

二 證書工作原理

以訪問https://www.google.com(https)舉例。
1. 瀏覽器發現此為HTTPS請求，握手拿到google的證書，先從系統(Windows)或者瀏覽器內置（Firefox）檢查證書鏈是否正確。
【補充】簡略步驟如下
a. 客戶端發送信息，帶上支持的SSL或者TLS版本(注意不同瀏覽器版本支持不同)
b. 服務器返回確認使用的加密通信協議版本以及加密隨機數和證書
c. 瀏覽器驗證證書 -> OCSP或者CRL 結合自帶truststore
注意此處驗證分為雙向驗證和單向驗證，單向驗證客戶瀏覽器即可完成，即客戶端truststore存放服務器public證書；雙向驗證客戶瀏覽器需要帶客戶端證書到服務器端由服務器端驗證，客戶端truststore存放服務器端public證書，keystore存放自身private證書，服務器端truststore存放客戶端public證書，keystore存放自身private證書。

 

2. 如果驗證失敗則會攔截(Edge瀏覽器)

3. 之后瀏覽器會嘗試查CRL(證書吊銷列表)和OCSP(在線證書檢查)，其中OCSP是前者的替代和新技術，這是由於CRL發布時間一般是7天(不過接到新通知要改為1天了）並且很大不方便。但是考慮到老瀏覽器只能用CRL，並且CRL可以緩存本地對於網速差情況還是有用的，此外Firefox雖然支持OCSP但是可以手動關閉也是CRL存在的原因。

注意：CA不會直接暴露到外網的，如果需要訪問CA服務器需要使用硬件Token並且多人在場錄像，且只能遠程訪問。OCSP相當於證書數據庫的備份而已是直接暴露在外網的可以通過HTTP或者HTTPS訪問
4. 如果發現證書並沒有被吊銷或者過期則瀏覽器對EV證書會顯示為綠色，對OV證書則是通過放行。否則彈出通知---該網站不可信(不同瀏覽器不同--Edge瀏覽器）

三 證書存在的問題

1. CA錯簽證書，最近比較經典的就是google被其他CA亂簽了證書，這在CA界是很恐怖的一件事。谷歌是怎么發現的呢？ 這就要提到chrome采用了不同的CA管理機制叫做CT Log，每個CA在簽證書前都要先把證書post到谷歌CA服務器去備份，這個谷歌就能知道自己的域名是不是被亂簽了。
2. 依然有可能發生中間人攻擊，比如使用真實CA簽發的證書(要求證書鏈完整，即該軟件必須有認證過的CA）替換掉要訪問的網站的證書（需要攔截底層請求），模擬瀏覽器去驗證OCSP等

轉自： https://www.zhihu.com/question/37370216/answer/74060132
參考： https://blog.csdn.net/junwua/article/details/80506399