我最近了解了一些关于 ocsp 的知识。我通过以下命令检查站点的 ocsp 装订：
$openssl s_client -connect www.stackoverflow.com:443 -status -servername www.stackoverflow.com
我发现我自己的站点和 stackoverflow 以及其他一些小型站点都有 ocsp 设置。他们OCSP Response Data在命令响应中有字段。
但是当我查看一些像google.com、github.com、facebook.com 这样的大网站时，他们没有这样的字段。我明白了OCSP response: no response sent。
那么为什么他们不使用它呢？
为了保护您的用户，作为 Web 服务器，您必须使用 OCSP must staple。但即使在这种情况下，您也需要考虑到给出的 OCSP 响应通常在多天内有效，因此攻击者可以在证书被吊销之前获得服务器证书的 OCSP 有效状态，并将其作为 OCSP 装订插入在对 Web 客户端进行中间人攻击期间的状态（当然，攻击者必须与破解证书并且证书已被吊销的攻击者相同）。因此，不支持 OCSP 装订且需要 OCSP 的浏览器将受到保护。不会支持 OCSP 装订的浏览器。这也是 OCSP 装订不适用的原因之一最终的选择。在某些情况下，避免安全漏洞的安全性较低，而在其他情况下，它是无用的。当然，即使尝试在 Internet 上获得更多信任也不错。
因此，像谷歌这样的大公司提供了其他方法来保护使用他们浏览器的客户和用户：与其他浏览器相比，他们希望为用户提供更安全的体验，因为他们的目标是获得更多用户。为此，Google Chrome 实现了专有的CRLSet机制。
相同的公司和其他公司还希望推广其他方式让人们在互联网上获得（重新）信任。例如，一些公司跟随谷歌推广证书透明机制。因此，从政治上讲，在他们的网站上实施 OCSP 装订并为 Internet 的另一种信任机制工作，这将是一个坏主意。
我读过的关于证书吊销和保护用户的方法的最佳论文在这里：https ://arstechnica.com/information-technology/2017/07/https-certificate-revocation-is-broken-and-its-一些新工具的时间/
我的回答是：可能是因为在响应中节省了更多字节。
Alexandres 的回答（特别是粗体字）对于 google.com 可能是正确的，但对于 facebook 却不是。
OCSP 装订响应将出现在每个 TLS 连接中，这需要很多字节。如果响应中不存在 OCSP 主食，为什么会发生这种情况？！客户端向原始服务器发送 OCSP 验证请求并缓存响应数天。对于像 google 和 facebook 这样的流行网站，用户一天会看到几次页面，通常 OCSP 响应会缓存在客户端，不需要 OCSP 请求（例如，只有 2% 的客户端需要实际的 OCSP 请求）。
因此，对于这个受欢迎的网站，删除 OCSP 装订（并为 98% 的请求节省 100 个字节）比让网站更快地处理 2% 的请求是更好的选择。