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的能力，但是客户端却一直需要这种验证的结果的。