行业新闻与博客

黑客获得 SSL 证书的私钥会怎样？CA 撤销了它。但是浏览器如何知道网站的证书是否已被吊销？OCSP 是您的 Web 客户端可以检查的一种方法…

在最终用户的浏览器通过 HTTPS 连接到网站之前，它需要知道该网站正在使用有效的 SSL / TLS 证书。但是，他们的客户端或您的 Web 服务器如何验证服务器的 SSL / TLS 证书是否有效以及是否出于某种原因而未被吊销？证书颁发机构（CA）使用的证书撤销状态检查有两种主要类型-证书撤销列表（CRL）和在线证书状态协议或 OCSP。当然，这两种吊销状态检查机制都有各种增强。不幸的是，我们无法涵盖所有​​内容，因此我们仅涉及本文中的部分内容。

但是 OCSP 到底是什么？它与证书吊销列表（CRL），OCSP 装订和 OCSP 必须装订有何不同？OCSP 协议在验证证书的吊销状态中扮演什么角色？我们从哪里去改进撤销检查过程呢？

什么是在线证书状态协议？

在线证书状态协议是 Internet 工程任务组（IETF）RFC 6960 中描述的 Internet 协议。当尝试连接到网站时，Web 客户端（浏览器）使用这种方法来确定 Web 服务器的 X.509 数字证书的吊销状态。因此，基本上，OCSP 协议是对网站证书的吊销状态的实时检查。它是使用 CRL 的替代方法。

OCSP 响应程序的作用是什么？

简而言之：OCSP 响应者= OCSP 服务器。人们经常根据其功能互换使用术语“ OCSP 服务器”和“ OCSP 响应程序”。OCSP 服务器属于颁发数字证书的 CA。它使用客户端在其 OCSP 请求中提供的证书的序列号来查找其吊销状态并对该状态进行“响应”。（因此其其他名称为“ OCSP 响应程序”。）

商业数字证书（包括 SSL / TLS 网站安全证书）由称为证书颁发机构的受信任第三方颁发，以标识和认证个人，组织或其他实体。因此，当 CA 吊销证书时，表示他们说该证书由于某种原因不再有效，并且该证书不可信任。但是，CA 需要一种方法来将该证书无效信息传达给用户的客户端和 Web 服务器。

这是证书吊销列表（CRLS）和开放证书状态协议起作用的地方。

OCSP 协议适用于网站安全和身份验证过程的地方

基本上，OCSP 是检查 SSL / TLS 证书的吊销状态的方法之一。

当您的浏览器尝试连接到网站的服务器时，它会参与一个称为 SSL / TLS 握手的过程。大多数网站仍然依赖 TLS 1.2 握手，但是支持 TLS 1.3 的平台开始逐渐增加。

作为 TLS 握手过程的一部分，客户端与 Web 服务器之间进行来回通信（往返）。TLS 1.2（较旧的协议版本）具有两次往返，而 TLS 1.3 仅具有一次往返。

                                                                                                            TLS 1.2 握手及其两次往返的说明。

                                                                                                            TLS 1.3 握手及其单次往返的说明。

这些握手的目的是验证服务器并在双方之间建立安全的加密连接。此过程的一部分涉及 Web 服务器将其 SSL / TLS 证书传递给最终用户的 Web 浏览器。

但是，您如何知道所传递的证书是有效的还是已被吊销？这就是证书吊销检查（例如 OCSP）发挥作用的地方。但是默认情况下，并非所有浏览器都使用在线证书状态协议-或者它们使用自己的版本的证书吊销检查机制来管理 CA 的 CRL 列表。例如，默认情况下，Mozilla Firefox 和 Google Chrome 禁用 OCSP 检查（尽管 Firefox 仍将其作为选项包含在设置中（请参见上面的屏幕截图）。稍后我们将详细介绍。

既然我们知道了导致证书吊销检查的原因，那么让我们袖手旁观，深入研究 OCSP 的工作原理。

您的客户端如何使用 OCSP 检查证书的吊销状态

                                                                                   Firefox 中可选的在线证书状态协议（OCSP）设置的屏幕截图。

让我们使用在线证书状态协议来分解证书吊销状态检查的工作，以提供更多的清晰度：

• 网站的服务器将其 SSL / TLS 数字证书发送给客户端。此信息包含有关由受信任的第三方 CA 签名的个人或组织的信息。


• 客户端将 OCSP 请求发送到 CA，以验证证书的状态。该请求信息包括证书的序列号。


• OCSP 响应者使用此数字来检查证书的状态。然后，它用以下三个答案之一响应客户端：

1. 好，


2. 已撤销，或


3. 未知。


4. 客户收到答案后，就可以允许或拒绝会话。但是，当浏览器具有“软失败”策略时（稍后会详细介绍），就会出现一个问题。

在线证书状态协议只是检查证书吊销状态的一种方法

好吧，让我们备份一下。检查数字证书吊销状态的主要方法有两种：CRL 和 OCSP。但是这两种方法也有增强或替代的方法：

• 集中式 CRL 数据，例如 CRLSets 和 CRLite（以前是 OneCRL），


• OCSP 装订，以及


• OCSP 必须装订。

那么，这些不同的机制或增强之间有什么区别？CRL 和 OCSP 首先将证书撤销状态检查的责任放在客户端，而 OCSP 装订（和 OCSP 必须装订）将责任放在网站的 Web 服务器上。

让我们简要介绍这些过程中的每一个，以更好地理解它们之间的联系和区别。

1.传统证书吊销列表（以及诸如 CRLSets 和 CRLite 的替代方案）

使用传统的 CA 证书吊销列表检查证书的证书吊销状态涉及到 Web 客户端与 CA 接触并下载其 CRL 的副本。这是一个资源密集型过程，它会减慢用户的 Web 客户端的速度，并带来糟糕的用户体验。

我们不想在本文中重新散列所有 CRL 的细节。（这将花费太多时间，所以无论如何这都不是您的原因。）因此，这里快速概述了基于 CRL 的证书吊销检查的工作方式：

CRL 证书吊销状态检查如何工作的说明

这是基于 CRL 的证书吊销状态检查如何工作的视觉效果。

                                                                               这是基于 CRL 的证书吊销状态检查如何工作的视觉效果。

要深入了解什么是 CA 证书吊销列表及其工作方式，请查看我们的其他文章。

CRLSets 和 CRLite

但是，我们之前提到过，有些浏览器已经根据 CA CRL 创建了自己的精选 CRL 数据集。例如，Google 为非 EV SSL / TLS 证书创建了自己的机制（CRLSets）。根据 ZDNet 的一篇文章：

“ Google 于 2012年决定  将 Chrome 默认设置为不检查非 EV 证书上的证书吊销。[…] 取而代之的是，Google 使用其 Chrome 更新机制来发送批次的已撤销证书的序列号，这些序列号是通过抓取证书颁发机构不断收集的。”

Firefox 在 2015年还推出了 OneCRL（其 The Chromium Project 的 CRLSets 用于 Google 的版本），但截至 2019年12月，现在已依赖 CRLite。但是，有趣的是，Firefox 不会自动检查短期证书（有效期少于 10 天的证书）的吊销状态。

2.在线证书状态协议  

好的，我们已经谈过在线证书状态协议。同样，此验证证书吊销状态的过程克服了 CRL 的主要问题，并提供了实时更新。客户端不必为每个请求都对整个 CRL 进行大量搜索，而是可以使用序列号检查单个证书的状态。

但是，OCSP 并不是完美的（尽管实际上是什么技术或协议？）。仍然需要客户端与 CA 联系以获取证书状态。因此，此过程：

让客户负责检查证书的撤销状态，

涉及对 OCSP 响应者（在本例中为 CA）的过多请求，

请求可能会超时或失败，从而导致我们前面提到的那些软失败，并且

CA 仍会收到有关用户的浏览历史记录，IP 地址以及他们可能更愿意保密的其他信息。

服务器提供的 OCSP 响应的一个问题是，浏览器被编程为以不同的方式响应。因此，即使浏览器收到表示证书状态未知的响应，而不是终止会话（也称为硬故障），它仍可以接受证书并启用连接（也称为软故障）。

就我而言，软故障策略在某种程度上不利于首先检查 CRL 的目的。如果浏览器无论如何都将允许连接，为什么首先要麻烦证书检查？

但是关于软失败策略和硬失败策略，我们已经足够介绍了检查证书吊销状态的第三种方法。

3. OCSP 装订

与以前的状态检查方法非常相似，OCSP 装订是使用在线证书状态协议的过程。但是，这是一种更高级的方法。与其依靠客户端执行证书吊销状态检查，不如将其责任放在 Web 服务器上。

OCSP 装订工作原理

• Web 服务器将定期的自动 OCSP 请求发送到 OCSP 响应器（CA）。如果可能的话，服务器会每隔几个小时（取决于其设置）频繁地进行一次“微调”。


• OCSP 响应器提供带时间戳的数据。响应该请求，OCSP 响应器将带有时间戳和 CA 签名的批准消息发送回 Web 服务器。


• Web 服务器缓存此带时间戳的响应。它使用此缓存的记录作为参考，直到它从 OCSP 服务器接收到新的更新。


• Web 服务器将缓存的，CA 签名的和带时间戳的数据发送到客户端。每当客户端尝试连接到 Web 服务器时，当服务器在 SSL / TLS 握手期间将 SSL / TLS 证书发送给客户端时，服务器可以“加盖”带时间戳的 OCSP 响应。客户信任此响应，因为它是经过数字签名并带有时间戳的。

拒绝基于客户端的吊销检查：为什么 OCSP 装订是更好的选择

通过 OCSP 装订，Web 服务器会经常与 OCSP 响应器进行通信，以获取最新的证书吊销状态信息。它会保存带时间戳的 OCSP 服务器响应的记录（缓存），以便在响应者不可用时从中提取。这减少了客户端的负载，并证明了更好的用户体验。它还可以使他们对您的网站合法并由您的品牌运营更有信心。

众所周知，虽然可以使用证书吊销列表，但是该过程有其局限性。一方面，这些列表并不总是经常下载到客户端，而且有时数量巨大。其次，使用 CRL 将责任放在最终用户的客户而不是 Web 服务器上。这只会造成不良的用户体验。

总体而言，OCSP 装订非常棒，并且肯定比 CRL 有了很大的改进。但是，如果客户端不知道所讨论的服务器是否支持 OCSP，该怎么办？这个问题继续困扰着 OCSP 装订。

输入 OCSP 必须装订

看到，OCSP 必须装订托运人吗？我们没有忘记你。

如果您听说过 OCSP 装订，那么您可能还听说过“ OCSP 必须装订”（或 OCSP 必须装订）。但是，如果没有，这个名词让我花一点时间来解释。该术语指的是证书扩展，它使客户端能够在收到 SSL / TLS 证书时就应该期望收到 OCSP 订书钉。目的是支持证书吊销过程。

亚太网络信息中心（APNIC）于 2019年底发表了一篇有关 OCSP 必需装订的出色文章。其中，它们提供了有关多少个领先的 Web 客户端实际支持 OCSP 装订和 OCSP 必需装订的数据：

OCSP 必须订书钉的优点（和缺点）

虽然 OCSP 必备品很有用，因为它可以克服 OCSP 的一些缺点，但坦率地说，这有点麻烦。为了使其正常工作，各方（CA，客户端和网站的服务器）必须可用并且运行良好。另一个问题是，并不是所有主要的网站都还支持证书扩展。

根据 APNIC 的文章：

我们首先观察到所有浏览器都在征求订书钉 OCSP 响应，这表明它们确实支持 OCSP 装订。但是，我们观察到，如果包含 OCSP Must-Staple 扩展名的证书中未包含装订的 OCSP 响应，则只有 Firefox（在所有台式机操作系统和 Android 上）会向用户显示证书错误。所有其他浏览器（包括 iOS 上的 Firefox）仅接受证书，甚至不向 OCSP 响应者发送自己的 OCSP 请求。

这些结果表明，客户基本上还没有准备好 OCSP 必须订书钉。但是，似乎所有客户端都已经支持 OCSP 装订，这意味着支持 OCSP Must-Staple 所需的额外编码工作可能不太重要。”

所有这一切都意味着，虽然 OCSP 必须装订是一个理想的选择，但它还不是完美的或确定的事情。还有更多工作要做，这绝对是要努力的事情。我们希望将来有更多的站点实施它-最好早些而不是晚些。

如果您想了解更多信息并想在自己的网站上实施，我们在 Venafi 的朋友撰写了一篇很棒的文章，介绍如何实施 OCSP Must-Staple。

关于 OCSP，OCSP 装订和 OCSP 证书撤销检查必不可少的最终思考

我们希望本文能为您提供丰富的信息，并使您对以下方面有所了解：

在线证书状态协议和 OCSP 装订是什么以及它们如何工作，

他们在网站安全中扮演的角色，

OCSP 装订如何以及为什么为您的最终用户提供更好（和更安全）的体验，以及

就采用 OCSP 必需品而言，我们作为行业仍然有改善的空间。

作为组织，我们知道您希望为您的网站访问者和客户提供最佳（和最安全）的体验。我们希望您不要主动让最终用户的浏览器来检查您站点的吊销状态来“赚钱”，而是希望您通过实施 OCSP 装订（或者此外，OCSP 必须装订）来主动提供该信息。 ）。

OCSP 装订是简化 SSL / TLS 握手身份验证过程的好方法。这样可以减少负载，并使用户更快地进入您的站点。但这并不完美。这就是为什么我们希望看到更多的人使用 OCSP 必须将证书吊销检查方法提高到新的水平。

本文由机器译制