我一直在研究HTTPS 的OCSP 装订，这看起来很有趣。据我所知，它本质上是一种将 CRL 从 CA 卸载到服务器的方法，允许在一个连接中完成所有操作，从而缓解一些隐私问题。从高层次的角度来看，这个过程是如何运作的？
我主要感兴趣的是：
CRL是一个对象，其中包含已被给定 CA 吊销的证书的序列号列表。它是一个签名对象；CRL 颁发者通常是 CA 本身（具有相同的密钥），但可以委托此权力。
OCSP 响应是 OCSP 响应者在收到有关证书吊销状态的请求时返回的内容。请求/响应协议在RFC 2560中指定。回复本身由回复者签名，可以独立生活；这意味着给定的 OCSP 响应可以被视为讨论单个证书的专用 CRL。
在证书验证期间，验证者（例如，Web 浏览器，在验证服务器的证书时）必须从其信任锚（又名根证书）之一构建证书链，验证所有签名、名称和扩展名，然后继续确定链中每个证书的吊销状态。最后一步需要获取 CRL 和/或 OCSP 响应、验证它们（这意味着验证它们的签名）并读取它们的内容。这提出了两种不同类型的问题：
CRL / OCSP 与证书匹配
让我们专注于以下设置：验证者想要获得证书T的撤销状态（作为“目标”）。他已经建立并验证了以 CA 证书C后跟T结尾的证书链，这意味着 T 上的签名与C中的公钥匹配。此外，C的撤销状态已经被验证，验证者现在感兴趣的是 T。T可以是一个终端实体证书（例如 SSL 服务器的证书）或另一个 CA 证书作为更长链的一部分，这超出T。
签署了 CRL；谁签署它是X.509和它在 Internet 上下文中的 PKIX 解释之间的细微区别的问题。对于“原始”X.509，如果 CRL 由具有有效证书并具有与CA相同的专有名称的实体签名，则它是有效的。如果 CRL 由与T相同的公钥（即 CA C的密钥）签名，则此方法效果很好：此时，C是经过完全验证的证书，因此其公钥可以“受信任”（验证者有理由确定公钥实际上由一个实体拥有，该实体以C中给出的名称命名subjectDN场地）。但是，它可以是具有该名称的任何其他证书，并且位于其自己的有效链的末尾（这可能意味着 CRL 的更多路径构建、验证和处理）。在 X.509 中，专有名称就是一切，因为 X.509 用于Directory，这是一个全球性的类似 LDAP 的服务器聚合，其中所有内容都由其专有名称唯一引用。
处理互联网的工作组 PKIX 注意到目录，尽管它可能很奇妙，但与像Mokèlé-mbèmbé这样的神话野兽有一些共同特征，特别是它似乎根本不存在（至少，不已报告确认目击事件）。相应地，PKIX 强制执行限制以控制麻烦：CRL 颁发者的证书必须位于以与以T结尾的路径相同的信任锚开头的路径的末尾。当两个彼此不认识的不同 CA 最终使用相同的专有名称时，这应该避免跨根问题（如果他们曾在目录的上下文中工作，如果存在的话，他们可能会立即注意到该问题）。这一点在RFC 5280中，第 6.3.3 节，步骤 (f)。
可以委托 CRL 颁发者的角色，在这种情况下，可以在T本身的CRL Distribution Points扩展中找到 CRL 颁发者的可分辨名称，并在 CRL 中找到匹配的扩展。Issuing Distribution Point
对于 OCSP 响应，使用了类似的系统。OCSP 响应可以由 CA 自己签名（使用C中的密钥）；或者可能有专门的发行人。那里的事情更受限制：当有一个专门的颁发者时，它必须有一个由C本身直接颁发的证书，并带有一个特定的扩展名，将其标记为 OCSP 响应者（Extended Key Usage使用id-kp-OCSPSigningOID，请参阅RFC的第 4.2.2.2 节2560 )。该响应者的证书可以附加到 OCSP 响应本身（在签名区域之外，但仍编码在同一个 blob 中）。
重要的一点是，如何获得 CRL 或 OCSP 响应并不重要：它们是签名对象，验证签名以及所有名称匹配和扩展内容就足够了。对象本身可以通过 TCP 连接、电子邮件、USB 密钥、骆驼车队、背诵并由莎士比亚演员宣布，等等。签名将这些细节抽象出来。证书、CRL、OCSP 响应不能在不使签名无效的情况下被“操纵”。
CRL 和 OCSP 响应具有有效期。它们都有一个thisUpdate字段，用于说明它们的发布时间（正式地，它们包含的信息被收集的日期）。它们还有一个nextUpdate字段，即应该发布较新版本的日期；因此，它作为一种到期日。预计验证者会缓存 CRL 和 OCSP 响应，使用这些日期来了解缓存的版本是否仍然可用，或者应该获得新的版本。
如何定位 CRL 和 OCSP 响应
CRL 或 OCSP 响应的分发方式对于安全性并不重要，但是，验证者当然不能凭空猜测 URL。可以下载 CRL 的 URL 编码在CRL Distribution Points证书T的扩展中（此扩展有两个角色：用于授权 CRL 发布权的验证角色，以及提供指向可以下载实际 CRL 的位置的指针的描述角色）。http://URL 很常见，但也有ldap://URL（尤其是在像企业网络这样的封闭环境中）。CRL 下载的https://URL 可能会导致循环（因为下载需要验证另一个 SSL 服务器的证书），因此它往往得不到很好的支持，或者根本不支持（Windows 不会遵循这样的 URL）。
同样，可以找到 OCSP 响应程序的 URL 位于Authority Information Access证书T的扩展中。
这些 URL 仅供参考；验证者可以使用它可以获得的任何 CRL 或 OCSP 响应，无论其来源如何，只要所有签名都经过验证。由于 CRL 和 OCSP 响应具有不可忽略的生命周期，因此缓存和重用它们是有意义的。OCSP 装订是 SSL服务器获取自己证书的 OCSP 响应并将其提供给客户端的一种方式，假设客户端可能需要它们。这使得整个过程更加高效：客户端不必打开额外的连接来自己获取 OCSP 响应，并且服务器可以在给定的时间范围内将相同的 OCSP 响应发送给所有客户端。一种查看方式是 SSL 服务器充当 Web 代理以下载 OCSP 响应。
OCSP 装订完全取决于 SSL 服务器；证书的内容和 OCSP 响应不受影响。CA 或 OCSP 响应者根本不需要知道装订发生。
从握手中“删除” OCSP 装订标志会在握手Finished结束时破坏消息，因此这对攻击者来说是不可行的，除非这会让他在结束之前破坏整个握手。但是，事实并非如此：缺少 OCSP 装订并不意味着客户端不会确定撤销状态；它只是意味着客户端将独自一人，并且必须自己获取 CRL 或 OCSP 响应。
OCSP 装订的不幸之处在于它尚未得到广泛支持。不过，这个想法是合理的。它的安全含义是，通过装订，SSL 服务器有一个强有力的论据来说服 Web 浏览器真正完成它的工作而不是完全跳过撤销状态检查，就像许多 Web 浏览器不幸倾向于做的那样（事情在这方面发生了变化，但慢慢地）。
注意： CRL / OCSP 响应生命周期通常从几分钟到几天不等。日期已根据客户的时间概念进行验证；时钟过期的客户可能会遇到麻烦。