瀏覽器如何驗證HTTPS證書的合法性？
比如說一個新的網站去買了ca證書，用戶通過瀏覽器去訪問，這時候瀏覽器如何去驗證這個證書的正確性，防止被中間人攻擊？ 是需要到ca網站上去驗證嗎還是？求詳細介紹在這一步做的事情。
簡單來說是驗證兩個問題：
1、證書是否是信任的有效證書。所謂信任：瀏覽器內置了信任的根證書，就是看看web伺服器的證書是不是這些信任根發的或者信任根的二級證書機構頒發的。所謂有效，就是看看web伺服器證書是否在有效期，是否被吊銷了。
2、對方是不是上述證書的合法持有者。簡單來說證明對方是否持有證書的對應私鑰。驗證方法兩種，一種是對方簽個名，我用證書驗證簽名；另外一種是用證書做個信封，看對方是否能解開。
我對瀏覽器的具體實現不大熟，我可以說下如何驗證數字證書的有效性這個問題。
要想驗證證書是否有效，要檢查三點：
1. 驗證證書是否在有效期內。
證書中會包含證書的有效期的起始時間和結束時間，取一個時間點去比較就好了。
關鍵問題是如何保證取到的時間點是可信的，這就是另外一個話題了。
2. 驗證證書是否被吊銷了。
被吊銷的證書是無效的。驗證吊銷有CRL和OCSP兩種方法。
CRL即證書吊銷列表。證書被吊銷後會被記錄在CRL中，CA會定期發布CRL。應用程序可以依靠CRL來檢查證書是否被吊銷了。
CRL有兩個缺點，一是有可能會很大，下載很麻煩。針對這種情況有增量CRL這種方案。
二是有滯後性，就算證書被吊銷了，應用也只能等到發布最新的CRL後才能知道。增量CRL也能解決一部分問題，但沒有徹底解決。
OCSP是在線證書狀態檢查協議。應用按照標準發送一個請求，對某張證書進行查詢，之後伺服器返回證書狀態。OCSP可以認為是即時的（實際實現中可能會有一定延遲），所以沒有CRL的缺點。不過對於一般的應用來說，實現OCSP還是有些難度的。
3. 驗證證書是否是上級CA簽發的。
每一張證書都是由上級CA證書籤發的，上級CA證書可能還有上級，最後會找到根證書。根證書即自簽證書，自己簽自己。
當你驗證一張證書是否是由上級CA證書籤發的時候，你必須有這張上級CA證書。通常這張證書會內置在瀏覽器或者是操作系統中，有些場景下應用系統也會保留。
---------
以上三點，只要有一個沒通過，這張證書就是無效的，不該信任。
在實際場景中會衍生出一些問題，比如：
1. 嚴格來說，證書狀態驗證「應該」是個「遞歸」過程：驗證完一張證書之後還得驗證上級CA證書，一直驗到根。這個開銷太巨大了，所以應用系統大多會做一些取捨。當然亂取捨的時候就有可能出問題。
2. 根證書的可信程度。根證書是整個信任體系的「根」，只有根證書可信，下級證書才可信。
---------
歡迎斧正。正常來說，是需要瀏覽器訪問CA站點去驗證證書的有效性的。
但這樣的話，會增加客戶端的響應時間，伺服器會針對這進行優化，在nginx層配置OCSP Staping
手機碼字，先佔個坑，一會到公司詳細回答
以下是乾貨====================================
首先，需要說明的是，Https加密通信有兩種加密，一種是非對稱加密，另一種是對稱加密。
非對稱加密，就是加密和解密的秘鑰不同，你訪問某https站點時，是可以知道這個站點的公鑰的，這個公鑰是CA機構頒發給這個站點的，所有人都可以知道，而私鑰是握在站點手裡的，只有該站點可以知道。
公鑰只能進行加密，而解密是只能用私鑰進行解密的。顯然，這樣的安全性很高，但有個很嚴重的問題就是，非對稱解密相當損耗CPU性能，https網站cpu損耗差不多90%的性能損耗都在非對稱秘鑰的解密上。全部內容都用非對稱加密交流性能大大下降。
而對稱加密，就是加密和解密都是用的同一個秘鑰，加密和解密都很快，在不知道秘鑰的情況下，想要破解的難度也非常大，比非對稱加密破解還要難。但有個問題就是，如果用對稱秘鑰的話，在第一次握手協商秘鑰的時候，很可能就已經被劫持，這時你的加密也就毫無安全性可言了。
所以，這裡就同時用到了兩種加密方式。
用非對稱秘鑰進行秘鑰協商，客戶端，把自己支持的對稱加密方式，通過公鑰加密以後發送到站點，如果此時被劫持，他劫持掉你發送的消息，在沒有私鑰的情況下，是無法解密的，也就無法仿造站點騙取你的各種信息了。如果沒有被劫持，正確發送到了站點，站點解密以後，會得到你支持的對稱加密方式，然後選擇一種性能和安全性最高的對稱加密方式，把對稱秘鑰和握手成功的消息加密，發送給你，你客戶端解密之後，就知道秘鑰和加密方式，接下來就可以進行下一步握手了。
以上，是CA防止被中間人攻擊的方式，至於驗證CA證書是否有效，是簡歷在SSL握手成功以後的事情的。
握手成功以後，你會得到CA機構的DNS和ip，解析DNS，訪問CA站點去校驗證書是否有效，此處要注意的是，客戶機的系統時間，如果系統時間不對的話，很可能證書會校驗失效。因為你系統的時間很可能不在證書的有效期範圍內。
而Https的一種優化方式，就是在Nginx配置 OCSP Stapling
因為很多CA站點時國外的，而你直接訪問CA站點來校驗的話，也許會花費很長時間。
Ocsp 全稱在線證書狀態檢查協議 (rfc6960)，用來向 CA 站點查詢證書狀態，比如是否撤銷。
通常情況下，瀏覽器使用 OCSP 協議發起查詢請求，CA 返回證書狀態內容，然後瀏覽器接受證書是否可信的狀態。
將證書保存下來，瀏覽器請求時候直接通過自己的伺服器發送回去，防止驗證伺服器出問題，還能加快訪問速度。
做證書的前來回答。(Update 1)
----------------------------------------------------------------
一 前提：
0. 證書存在的目的就是避免中間人攻擊，避免發生經典的傳令兵問題。
1. 證書都是由CA組織下認可的根證書Root簽發的（其中有兩種形式，第一種是該組織有一個Root，每一家的Root Ca都需要其簽名，該方案基於利益考量幾乎沒人採用，而是第二種方案，每家都有自己的Root CA 可以自簽或者互相簽名)。這個組織很難進，目前幾乎完全由歐美控制,每年都有輪值主席負責該年CA組織工作，主要涉及到新的RFC審核和修改，新的CA申請和已有CA日誌審核以及提出新的CA方案等。其他不通過該組織認證的證書籤發者都是不安全的，此外該組織會對每年每個CA簽發的證書進行審核。因此可以保證正常途徑簽發的證書根是絕對可信的。所有改組織通過的CA會強迫瀏覽器和系統安裝(常見的廠商有VeriSign, Microsoft, Oracle和Molliza 這也是強制力的來源)
2. 證書分為DV(Digital Verification)，OV(Organization Verification)和EV(Extended Verification)，其中EV證書最貴，可以在瀏覽器中看到綠色的就是EV證書。證書從申請到批准要走很久的流程，需要提供很多的公司認證信息和個人信息，否則是不會通過的。因此可以保證簽發的證書內容是可信的。
3. 證書是需要預裝的，特別是根證書。IE和Chrome是通過內置在Windows系統中的TrustStore來管理根證書（當然自己也可以手動導入自簽證書，瀏覽不會認可的因為有OCSP和CRL--之後細講）；而Firefox則是內置在自己的瀏覽中。
4. 綜上，通俗的來說一個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等
其他概念不說了，有效期之類的驗證也不說了。只說數字證書的真實性和可信性驗證。
CA下發給網站的證書是分層的證書鏈，從根證書開始一層一層直到網站證書。要驗證某一層證書是否確實由上級CA發放的需要驗證附帶在該證書上的由上級CA通過簽名函數及私鑰生成的數字簽名。數字簽名的解密需要上級CA的公鑰，這個公鑰就明文保存在證書鏈中的上層證書中。而根證書是自己給自己簽名，也就是根證書的簽名也是靠自己保存的公鑰來解密。這就解決了真實性問題，也就是能證明最底層的網站證書確實是證書中標明的CA發放的。
而可信性是看根證書是否在操作系統或瀏覽器內置的根證書列表中，如果在的話那麼這個證書鏈就可信的。
證書可靠性(真實並可信)驗證過程是一個信任鏈的驗證過程，需要明確三點：
1.瀏覽器中預置了一些可信根證書；
2.證書的簽名是由上級頒發者的私鑰加密的；
3.信任鏈的驗證終止與一個可信的證書。
可以參考：SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate?
上文中描述的比較清晰，但有個問題沒有描述清楚，何時、從哪獲取非根證書的頒發者證書？
上圖火狐中打開百度的證書，可以看到有個擴展欄位：授權信息訪問，這裡面包含的URI可以下載下來，導入鑰匙串工具，發現下載下來的crt證書就是頒發機構的證書GlobalSign**** CA - SHA256 - G2，這說明網站的證書里是包含上級頒發機構的證書獲取地址的
其實是校驗CA的根證書，根證書有效就是可信任，系統和瀏覽器有維護的可信任證書列表。所以不要隨便添加亂七八糟的根證書
可以參考這個帖子：iOS 中對 HTTPS 證書鏈的驗證
驗證ca證書的過程車很容易
首先要知道一下幾個事情
ca證書是收認可的ca機構簽發的
ca機構本身也是有證書的(存在公鑰和私鑰)
瀏覽器本身內置了收信可的ca機構的證書(有公鑰)
伺服器提供的證書當中存在"簽名"
證書中的"簽名"是經過私鑰加密過的證書hash值
當客戶端接收到了服務端提供的證書之後,會根據證書的內容進行散列計算得到證書內容的hash值,還會通過瀏覽器內置的證書(ca)提供的公鑰對簽名進行解密.
如果存在任何一個內置證書的公鑰解出的簽名內容和瀏覽器本身根據證書內容計算出的值相同,則認定該證書是有效的.
簡單來說 證書中的內容和簽名是匹配的 但是簽名是經過ca機構本身的秘鑰加密過了 如果證書被更改或者不是本ca機構簽發 那麼無法被瀏覽器內置的證書中的公鑰解出正確的內容 就和證書的內容不匹配了
當然也會驗證有效期或者是否被吊銷的
第一，檢查SSL 證書的根證書頒發機構是否受瀏覽器信任。
第二，檢查SSL證書中的證書吊銷列表，檢查證書是否被吊銷。
第三，檢查SSL證書是否在有效期內。
第四，檢查部署SSL證書的網站域名與證書頒發的域名是否一致。
第五，瀏覽器核對該網站是否存在於欺詐網站資料庫中。
經過這5個方面的檢查後，瀏覽器才會在頁面正常顯示安全鎖標誌，並顯示部署了SSL證書的加密頁面。易維信http://evtrust.com
證書檢測不是強制的,如果ca機構的檢測伺服器宕機,只會檢測本地的根證書列表.
看是誰頒發的和有效期？
推薦閱讀：