从证书的扩展项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表示该请求未经过授权。