OCSP是什么

OCSP（Online Certificate Status Protocol），中文翻譯是在線證書狀態協議，是維護服務器和其它網絡資源安全性的兩種普遍模式之一。另一種更老的方法是證書注銷列表（CRL）已經被在線證書狀態協議取代了很多年了。OCSP克服了證書注銷列表（CRL）的主要缺陷：必須經常在客戶端下載以確保列表的更新。

CRL協議，這個協議的思路是客戶端通過定期的去CA那里請求一個被吊銷的證書列表，作為本地緩存，從而之后對服務器證書的驗證就可以依賴這個緩存。但是這個方案需要客戶端去管理一個本地緩存，這相當于把所有的責任都扔給了客戶端。客戶端訪問CA的服務器的帶寬和穩定性都存在疑問，所以這種方案是注定要輸給服務端的解決方案的。

OCSP是TLS協議的擴展協議，在TLS的使用中，客戶端無法判斷一個還沒有過期的證書是否被吊銷了。因為CA在頒發了證書之后大部分情況下都是等待這個證書過期了之后的自然失效，而如果CA出于某些原因要人為的吊銷某個證書就沒有了辦法。這個時候客戶端在從服務端拿到了一個證書之后，去找服務端的接口去驗證一下這個證書的是否過期這一信息。

當用戶試圖訪問一個服務器時，OCSP（在線證書狀態協議）發送一個對于證書狀態信息的請求。服務器回復一個“有效”、“過期”或“未知”的響應。協議規定了服務器和客戶端應用程序的通訊語法。在線證書狀態協議給了用戶的到期的證書一個寬限期，這樣他們就可以在更新以前的一段時間內繼續訪問服務器。

但客戶端由于網絡有各種各樣的情況，每個連接去驗證國外的服務器的話就會帶來完全不可控的用戶體驗和訪問延時，并且對于CA來說也是一個不小的并發連接。所以OCSP一般會被應用到服務端，給客戶端節省這部分的時間。服務端周期性的去連接CA的OCSP服務器，驗證一個證書的合法性，存儲在本地。當客戶端與服務端進行TLS握手的時候，服務端在傳送了證書鏈之后（certificate消息），會繼續再傳輸一個certificate status消息，這個status消息就是服務端從CA的OCSP服務器那里獲得而來的證書吊銷狀態信息，雙方仍然是通過密碼學的方式保證了客戶端可以確認這個確認消息來源于CA。

OCSP與傳統的CRL比較有以下特點：

? 由于相對于傳統的CRL，一個ocsp響應包含的信息更少，故ocsp能夠更有效利用網絡和客戶資源

? 用OCSP，客戶無需自己解析CRL證書吊銷列表，但是客戶需要存儲狀態信息，而由于客戶側需要維護存儲緩存，故導致存儲信息很復雜。在實際使用中，這點帶來的影響卻很小，由于第三庫提供的相關接口已經幫我們完成此類工作

? OCSP通過專用網絡、專用證書、在特定的時間公開其服務。OCSP不強制加密，故可能帶來信息泄露的風險。

OCSP的調用流程如下：

1. OCSP服務器與CA數據庫建立數據庫連接；

2. 應用程序使用OCSP客戶端接口查詢指定證書的狀態；

3. OCSP客戶端接口封裝OCSP請求；

4. OCSP客戶端接口與OCSP服務器建立HTTP連接；

5. OCSP客戶端接口通過HTTP連接發送OCSP請求到OCSP服務器；

6. OCSP服務器解析OCSP請求；

7. OCSP服務器直接查詢CA數據庫，獲得最新證書狀態；

8. OCSP服務器封裝并簽發OCSP響應；

9. OCSP服務器通過HTTP連接返回響應；

10. OCSP客戶端接口關閉HTTP連接；

11. OCSP客戶端接口解析OCSP響應；

12. OCSP客戶端接口返回證書狀態給應用程序。

那么OCSP現如今就的到了全面的應用了嗎？并不是，實際上Chrome自己搭建服務器維護了一套CRL列表，所以Chrome瀏覽器可以不用去CA那里每次去查看一下這個證書是否過期。但是CRL是個逐漸過時的技術，新的技術是OCSP，本質上OCSP解決的問題與谷歌自己搭建CRL服務器解決的問題都是一樣的，就是一個在服務器端異步的去完成對證書有效性的檢查的問題。因為這個證書有效性的檢查是延時非常高的。在網易的服務器到Let’s Encrty測試的速度還是可控的，但是到亞信的服務器的延時將達到十幾秒。這種級別的延時如果讓用戶的客戶端每次都去做的話，客戶端根本沒辦法使用。

所以，到底是業務的服務器來做這件事還是瀏覽器自己搭建服務器去做這件事本質上都是一樣的。按照市場的角度分析，最終很可能一直會保持谷歌的這種CRL服務器的模式，因為不可能要求所有的服務器都提供OCSP的能力，但是客戶端卻一直需要這種驗證的結果的。