從證書的擴展項CRL分發點可以看到，CRL證書吊銷列表，是服務器身份驗證的一部分，驗證證書除了校驗簽名值外，還要校驗證書的吊銷狀態，如果一張證書已過期，或者被吊銷，那麼身份校驗失敗。要注意的是，證書過期並不代表其被吊銷，證書過期了便無效，如果證書沒有過期，但因爲某種原因被吊銷了，也一樣無效。我們知道，瀏覽器校驗證書吊銷狀態時，會通過CRL分發點找到CRLs文件的URL，然後去下載CRLs文件，從中尋找是否存在被校驗證書的序列號等信息，以此判斷證書的吊銷狀態，看似沒什麼問題，不過隨着CA機構簽發的證書越來越多，被吊銷的證書也越來越多，CRL的效率就變低了。
CRL問題
爲什麼說隨着簽發的證書越多，被吊銷的證書越來越多，CRL的效率就越低？首先CRLs文件中保存了所有被吊銷的服務器證書序列號和其被吊銷的原因等信息，注意是所有被吊銷的證書都保存在裏面。CRL校驗是同步操作，也就是說，CRL校驗未完成時，TLS/SSL握手過程是阻塞的，如果CRLs文件越來越大，那麼下載需要的時間就會變久，降低了整個握手效率。爲了解決這個問題，瀏覽器會去定期緩存CRLs，但是在客戶端定期緩存CRLs會帶來什麼樣的問題呢，如果一張證書剛剛被吊銷，客戶端沒有及時更新CRLs文件緩存，那麼在校驗時，仍舊使用了舊的CRLs緩存，會導致錯誤的身份校驗。
總的來說，CRL問題有三個，第一隨着CA機構簽發的證書越來越多，CRLs文件將越來越大，導致瀏覽器校驗服務器身份時，下載CRLs文件會越來越耗時，從而影響了TLS/SSL握手階段的時間。第二是校驗安全問題，CA機構在吊銷一張證書後，不會立刻去更新CRLs文件，客戶端定期緩存的CRLs文件也不是及時更新的，所以會導致一種情況是，某張證書被吊銷後，由於CRLs文件沒有及時更新的緣故，身份校驗通過了，認爲該張證書沒有問題。第三個就是CRL校驗是同步操作，會阻塞TLS/SSL協議的握手，也就是說，如果CRL校驗未完成，整個TLS/SSL握手階段都會被阻塞。
OCSP和CRL的區別
OCSP（Online Certificate Status Protocol）在線證書狀態協議同樣是用來做服務器身份校驗，由CA機構管理，使用數字簽名技術保護，瀏覽器可以從中獲得證書的吊銷狀態和吊銷原因，方式是由身份校驗方瀏覽器發送OCSP請求，等待響應來完成證書狀態獲取。
OCSP和CRL的區別在於，首先CRL是TLS/SSL協議標準的一部分，而OCSP屬於TLS/SSL協議的一部分。OCSP的更新更快速，由於是在線服務，一張證書的吊銷會及時更新OCSP服務。其次是，對於CRL校驗，瀏覽器需要先下載完整的CRLs文件，再從中查找序列號來校驗證書的吊銷狀態。OCSP則不需要下載，瀏覽器通過發送證書信息查詢請求，由OCSP響應返回該證書的吊銷狀態，因此，OCSP校驗速度要比CRL快很多。OCSP比CRL快的原因還有一個是，由於CRL和CCSP都由數字簽名技術確保完整性，那麼在校驗時，也要校驗CRL或OCSP的完整證書鏈，對於CRL，校驗證書鏈需要瀏覽器自行一級一級往上校驗，而對於OCSP，完整的證書鏈由響應信息時一同提供，所以節省了瀏覽器的校驗時間。
OCSP模型
CRL內部結構種會保存有被吊銷證書列表，所以文件會越來越大，看看OCSP在線證書狀態協議的結構種都包含有哪些信息。
請求和響應
OCSP服務和CRL最大的不同就是，CRL需要身份校驗方下載CRLs文件，從中查找證書是否處於被吊銷狀態，OCSP則是由身份校驗方發送證書查詢請求，查詢某一張證書的吊銷狀態，然後由OCSP服務也就是CA機構發送響應返回給證書的吊銷狀態到請求端。所以，OCSP肯定包含請求和響應兩部分：
一個OCSP請求結構包含兩部分，請求結構tbsRequest和可選的簽名信息optionalSignature。簽名信息就不詳細展開，在第6行可以看到，簽名信息包含的有簽名算法，簽名值和證書鏈certs。看第12行的請求結構tbsRequest，OCSP請求方發出的請求結構種包含協議版本號，requestorName顧名思義請求者名稱，requestList表示待校驗證書的信息，最後一個是可選的擴展項。
重點來看這個requestList，它的結構就是第19行的Request，裏面包含了最重要的請求信息，reqCert表示請求的證書信息，類型爲CertID，CertID的結構緊接着在下面，hashAlgorithm屬性標識使用的哈希算法，issuerNameHash標識請求方對服務器證書的使用者名稱進行簽名，issuerKeyHash標識請求方對服務器證書的公鑰進行簽名，最後的serialNumber標識需要校驗的證書的序列號。
請求結構看完了，到響應結構：
OCSP響應結構OCSPResponse中，responseStatus標識請求狀態成功或者失敗，responseBytes裏面存放了響應信息。第45行可以看到，responseBytes裏存放了一個responseType表示響應類型，相應類型有兩種，這裏總結它的基本類型BasicOCSPResponse。第50行，tbsResponseData是最重要的，OCSP響應部分，signatureAlgorithm標識簽名算法，signature標識簽名結構，這些都可以看出來，certs標識證書鏈，這個在前面請求結構中也有出現。
最後是展開這個tbsResponseData，第57行，作爲響應的主體部分，裏面包含的屬性有version協議版本號，responderID響應ID，producedAt標識請求完成時間，responses屬性最重要，標識請求校驗的服務器證書狀態。第65行就是responses的類型，SingleResponse，裏面包含屬性有certID，校驗證書的序列號，certStatus，校驗證書的狀態，thisUpdate和nextUpdate分別標識本次和下次響應更新時間，最後一個singleExtensions是可選的擴展項。
證書鏈保護
前面說過，OCSP也需要數字簽名技術保護，也要校驗證書鏈，因爲OCSP服務由CA機構提供，OCSP在使用數字簽名技術簽名證書時，可以用簽署該服務器的私鑰進行簽名，也可以是簽署該服務器的CA機構授權的其他機構對其進行簽名。對於OCSP請求校驗方來說，如果在OCSP響應中沒有簽名證書鏈，請求方時可以選擇不校驗簽名的，直接讀取證書的吊銷狀態，當然也可以選擇自行構建證書鏈來校驗，因爲CA機構的根證書都集成在了瀏覽器中。如果OCSP響應中包含了證書鏈，那麼就必須去校驗它。
異常狀態
在前面的響應結構responseStatus中存放的是響應狀態，如果證書請求在校驗時發生一些錯誤，會在響應結構中表示出來，狀態一共有6種：
- 如果校驗成功，狀態爲successful。
- internalError表示遇到內部錯誤，需要請求方重新發送OCSP請求。
- malformedRequest表示請求語法有錯。
- tryLater表示OCSP服務暫時不可用。
- sigRequired表示請求方對OCSP請求進行簽名。
6、最後一個unauthorized表示該請求未經過授權。
