簡介
我們在進行網頁訪問的時候會跟各種各樣的證書打交道，比如在訪問https網頁的時候，需要檢測https網站的證書有效性。
OCSP就是一種校驗協議，用於獲取X.509數字證書的撤銷狀態。它是為了替換CRL而出現的。
本文將會詳細介紹OCSP的實現和優點。
PKI中的CRL
我們知道在PKI架構中，CA證書是非常重要的元件，客戶端通過CA證書來驗證服務的可靠性。對於CA證書本身來說在建立的時候是可以指定過期時間的。這樣證書在過期之後就不可以使用，需要申請新的證書。
但是隻給證書指定過期時間是不夠的，比如我們因為業務的需求，需要撤銷證書怎麼辦呢？
PKI中提供了一個叫做CRL(certificate revocation list)的機制，用來維持被廢除的證書列表。
這個CRL是由CA來頒發的，一般是在證書過期之前生成的。因為如果證書已經過期了，那麼這個CRL是無意義的。
對於CRL本身來說，它是一個證書列表，裡面證書的格式通常也使用的是X.509。
CRL一般是由釋出證書的CA來維護和釋出的，釋出CRL的元件叫做CRL issuer，通常來說CRL issuer和CA是同一個服務，但是你也可以根據需要將CRL issuer和CA進行拆分。
CRL是由CA定時來發布的，當然你也可以按照需要在需要撤銷某個CA證書的時候重新發布CRL。所有的CRL都有過期時間，在這個過期時間之內，客戶端可以根據CRL中的簽名，去CA驗證CRL的有效性，從而防止CRL的偽造。
CRL的缺點
那麼CRL有什麼缺點呢？
首先CRL維持的是一個撤銷的證書列表，為了保證系統的有效性，客戶端在每次校驗CA證書有效性的時候，都需要從CA伺服器中獲取這個CRL。然後通過CRL來校驗對應的CA證書狀態。
如果每次都去拿這個CRL，就有可能會有下面幾個問題。
第一個問題是，如果CRL不可用，那麼客戶端就拿不到這個CRL，也就無法校驗CA證書的狀態，從而造成服務不可用。
另外一個問題是，如果要撤銷的證書比較多的話，這個CRL可能會比較大，從而造成網路資源的浪費。
最後一個問題是PKI證書體系本身的目的是建立一個可以自我校驗的，不依賴於線上服務的安全體系，如果每次都要線上獲取CRL的話，就是去了PKI的這一優勢。
CRL的狀態
雖然CRL維持的是一個撤銷證書列表，但是這個列表中證書的狀態還是有所不同的。
CRL中證書的狀態有兩種，第一種就是證書已經被撤銷了，比如證書的頒發機構CA發現之前的頒佈的證書是錯誤的，或者因為其他的原因如私鑰洩露導致原來的證書不夠安全，需要將證書撤回。或者證書機構因為未遵守某些策略導致證書被吊銷等，都需要將之前的證書設定為撤銷狀態。
還有一種狀態是一個臨時撤銷的狀態，這裡叫做Hold狀態，它表示證書暫時是無效的，比如在使用者沒有確定私鑰是否丟失的情況下。當使用者最終找回了私鑰，則這個證書還是可以被恢復的。
OCSP的工作流程
既然CRL有這麼多缺點，所以一個用來替代CRL的OCSP協議出現了。
我們先來看一下OCSP的工作流程。
假如A和B要進行使用PKI進行通訊。為了保證通訊的安全性，A將自己的公鑰發給B，並告訴B，這是我的公鑰，你可以用這個公鑰來校驗我傳送給你的訊息。
B在收到A的公鑰之後，並不能確定A的公鑰就是正確的，沒有被篡改的。於是從A的公鑰中提取出serial number,並將其封裝到一個'OCSP request'中發給CA伺服器。
CA伺服器中的OCSP responder讀取到了'OCSP request'請求，並從中提取出A的公鑰的serial number。OCSP responder從CA伺服器的資料庫中查詢這個serial number是否在這個資料庫被撤銷的列表中。
如果發現不在，那麼意味著A的公鑰仍然是有效的，OCSP responder將會傳送一個簽名後的OCSP response給B。
B通過使用CA伺服器的公鑰驗證OCSP response的有效性，從而確認A的公鑰仍然有效 。
最後B使用A的公鑰和A進行通訊。
OCSP的優點
從上面的OCSP的工作流程我們可以大概總結出下面幾個OCSP相對於CRL的優點。
首先OCSP響應的資料量要比CRL要小，所以對網路的要求和壓力更少。
另外因為OCSP響應要解析的資料更少，所以OCSP客戶端的實現要比CRL更加簡單。
雖然因為CRL的各種缺點，在web環境中已經不再被使用，而是被更加高效的OCSP替換，但是CRL仍然被執行在CA的其他環境中。
OCSP協議的細節
OCSP協議是在RFC 6960中定義的。
OCSP協議可以分為請求協議和響應協議兩部分，接下來分別來進行介紹。
OCSP請求
一個OCSP請求需要包含協議版本號，請求服務,要校驗的證書identifier和可選的擴充套件部分。
OCSP responder在接收到OCSP的請求之後，會去校驗OCSP訊息的有效性，如果訊息有問題則會返回異常,否則的話會根據請求的服務進行處理。
OCSP請求如果用ASN.1(Abstract Syntax Notation One)抽象語法標記這可以如下表示：
OCSPRequest ::= SEQUENCE {
tbsRequest TBSRequest,
optionalSignature [0] EXPLICIT Signature OPTIONAL }
TBSRequest ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
requestorName [1] EXPLICIT GeneralName OPTIONAL,
requestList SEQUENCE OF Request,
requestExtensions [2] EXPLICIT Extensions OPTIONAL }
Signature ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL}
Version ::= INTEGER { v1(0) }
Request ::= SEQUENCE {
reqCert CertID,
singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING, -- Hash of issuer's DN
issuerKeyHash OCTET STRING, -- Hash of issuer's public key
serialNumber CertificateSerialNumber }
ASN.1是一個介面描述語言，通過ASN.1，我們可以很清晰的描述資料的格式資訊。
一個OCSPRequest是由可選擇簽名的OCSP請求tbsRequest和對應的簽名optionalSignature組成的。
其中TBSRequest中包含了版本號，OCSP requestor的名字，證書的狀態列表requestList，可選的擴充套件資料這幾項組成的。
OCSP響應
對於OCSP的響應來說，根據傳輸協議的不同它的結構也是不同的。但是所有的響應都應該包含responseStatus欄位表示請求的處理狀態。
OCSP響應用ASN.1格式來表示如下所示：
OCSPResponse ::= SEQUENCE {
responseStatus OCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
OCSPResponseStatus ::= ENUMERATED {
successful (0), -- Response has valid confirmations
malformedRequest (1), -- Illegal confirmation request
internalError (2), -- Internal error in issuer
tryLater (3), -- Try again later
-- (4) is not used
sigRequired (5), -- Must sign the request
unauthorized (6) -- Request unauthorized
}
ResponseBytes ::= SEQUENCE {
responseType OBJECT IDENTIFIER,
response OCTET STRING }
responseStatus是響應的狀態，responseBytes是可選的響應結果。
這裡的response是一個BasicOCSPResponse物件的DER編碼：
BasicOCSPResponse ::= SEQUENCE {
tbsResponseData ResponseData,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
OCSP stapling
可以看到OCSP需要客戶在需要檢視證書是否被吊銷的時候，需要向OCSP responser請求，以確認證書的有效性。
但是這種方式實際上洩露了使用者的隱私資訊，因為OCSP responser知道了客戶端需要校驗的證書，就知道客戶端正在訪問的網站。
於是引入了OCSP stapling來解決這個問題。
那麼什麼是OCSP stapling呢?
OCSP stapling是直接將OCSP證書放到客戶端要訪問的web伺服器上，因為OCSP證書是新增了時間戳和數字簽名的，所以可以保證其正確性。
這些OCSP證書會在客戶端和web端建立SSL 握手的時候就包含在OCSP響應中。
這樣客戶端不需要單獨和CA建立額外的連線，從而提高了效能。
OCSP stapling需要在伺服器端主動開啟。
如果你用的是apache伺服器，首先需要版本大於2.3.3。
然後需要在.conf檔案中的<VirtualHost></VirtualHost> block外部新增：
SSLStaplingCahe shmcb: /tmp/stapling_cache(128000)
然後在<VirtualHost></VirtualHost> block的內部新增：
SSLUseStapling On
如果你用的是nginx，首先需要版本大於1.3.7。
然後在nginx的配置檔案server {} block中新增：
ssl_stapling on;
ssl_stapling_verify on;
如果你想驗證一個網站是否開啟了OCSP stapling，可以到https://entrust.ssllabs.com/網站中進行查詢：
在這個網站中，你可以輸入任何要查詢的網站地址，然後可以得到下面的資訊：
可以看到這個網站是開啟了OCSP stapling的。
總結
OCSP和OCSP stapling是非常有用的證書撤銷校驗協議，已經被廣泛的使用。大家可以檢查一下自己的網站有沒有用到哦。
更多內容請參考 http://www.flydean.com/43-pki-ocsp/
最通俗的解讀，最深刻的乾貨，最簡潔的教程，眾多你不知道的小技巧等你來發現！
歡迎關注我的公眾號:「程式那些事」,懂技術，更懂你！