简介

咱们在进行网页拜访的时候会跟各种各样的证书打交道，比方在拜访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/

最艰深的解读，最粗浅的干货，最简洁的教程，泛滥你不晓得的小技巧等你来发现！

欢送关注我的公众号:「程序那些事」,懂技术，更懂你！