互联网安全通常会成为安全性，功能性和用户体验的微妙跳动。 一个典型的例子是将浏览器与CA提供的有关吊销证书的信息联系在一起的努力。 该常见问题解答定义了一段时间以来用于此目的的主要机制，包括 证书撤销列表, OCSP, OCSP装订 和 必须装订，以及最近的一次 CRLite.
CA最初尝试通过以下方式发布其已颁发证书的撤销状态： 证书吊销列表（CRL）。 CRL只是CA在计划的到期之前曾经吊销的所有证书的列表。 这些由CA定期更新，并且要求浏览器在每个HTTPS连接之前检查它们。 随着时间的流逝，CRL的大小不断增加，每个浏览器对其进行审查的任务也都在增加。 随着下载和解析大型（且不断增长的）CRL所需的时间增加，用户的延迟也增加了。 为了减轻这些问题，浏览器和CA开发并实施了在线证书状态协议（OCSP）。
最低价的 在线证书状态协议（OCSP） 是网络浏览器用来确定SSL /TLS HTTPS网站提供的证书。 而SSL /TLS 证书总是以到期日期颁发，在某些情况下，必须在证书到期之前将其吊销（例如，如果其关联的私钥可能已被破坏）。 因此，无论证书的到期日期如何，客户都必须始终检查网站证书的当前有效性。
OCSP最简单的形式如下：
1. Web浏览器从HTTPS网站接收证书。
2. Web浏览器向OCSP响应器发送请求，OCSP响应器是由颁发证书的证书颁发机构（CA）运营的服务器。
3. OCSP响应者对浏览器的签名响应表明证书是有效的还是已被吊销。
不幸的是，OCSP带有许多问题。 许多OCSP实施不够可靠，这迫使不耐烦的浏览器和其他客户端软件以软故障模式实施OCSP检查。 这意味着，如果在响应时无法及时访问OCSP服务器，则该证书将被视为有效，并且将继续进行HTTPS连接。
中间人攻击利用阻止的OCSP查询或连接，利用被盗的证书来访问受信任的HTTPS连接，从而利用了这一点。 这可能导致敏感信息与不良行为者共享，从而导致OCSP装订作为解决方案。
最初引入OCSP是为了解决证书吊销列表（CRL）的带宽和扩展问题，但OCSP却引入了一些自身的性能和安全性问题，目前正在通过以下方式解决这些问题： OCSP装订。 在OCSP装订中：
1. Web服务器从OCSP响应器请求并获取其证书的签名OCSP响应，该响应最多可以缓存7天。
2. 服务器在对Web浏览器的HTTPS响应中包括缓存的OCSP响应以及其证书（或“装订到”）其证书。
3. 为了防止潜在的攻击，其中网站提供了被盗的吊销证书而没有OCSP临时响应，则可能会发布带有必需钉扩展名的证书，并要求对证书进行OCSP装订。
由于MITM攻击者的恶意举动，CA和浏览器供应商引入了SSL证书的扩展，称为 OCSP必须装订 （在 RFC 7633，尽管此处未将其称为“ OCSP必须装订”）。
OCSP Must-Staple要求对证书进行OCSP装订。 如果浏览器在没有OCSP装订的情况下接触到证书，则该证书将被拒绝。 Must-Staple不仅减轻了降级攻击的威胁，而且还减少了流向CA OCSP响应程序的不必要流量，从而提高了响应速度和整体OCSP性能。
CRLite 是新提议的标准，它将发送有关所有已撤销的SSL /TLS 证书直接发送给浏览器。 通过将有关已撤销的CA的信息直接集成到浏览器中，可以潜在地消除所有繁琐的过程以及浏览器与CA之间不可靠的连接。
一个主要的问题可能是存储的信息量巨大，这是因为CRL的规模和规模在不断增长，并且日益增长，这是OCSP流程的核心问题之一。 CRLite使用布隆过滤器 压缩大量数据，使浏览器更易于管理。
如果证书太新，这意味着尚未包含在任何更新中，然后浏览器将使用OCSP（装订或主动查询）。
