为了保护您的用户，作为Web服务器，您必须使用OCSP must staple。但即使在这种情况下，您也需要考虑到所给出的OCSP响应通常在多天内有效，因此攻击者可以在证书被吊销之前获得服务器证书的OCSP有效状态，并在其对Web客户端的MitM攻击期间将其作为OCSP装订状态插入（当然，攻击者必须是攻击证书的同一个人，并且证书已被撤销）。因此，一个浏览器，不支持OCSP装订，需要OCSP，会受到保护。支持OCSP装订的浏览器不会。这就是为什么OCSP装订不的原因之一最终的选择。在某些情况下，它是一种不太安全的方法来避免安全漏洞，而在其他一些情况下，它是无用的。即使它是一个不错的尝试，以获得更多的信任在互联网上，当然。
因此，像谷歌这样的大公司提供了其他方法来保护他们的客户和使用他们浏览器的用户：他们希望为他们的用户提供比其他浏览器更安全的体验，因为他们的目标是获得更多的用户。为此，谷歌Chrome实现了专有的CRLSets机制。
同样的公司和其他公司也想推广其他方式让人们在互联网上获得（恢复）信任。例如，一些公司跟随谷歌推广**Certificate Transparency**机制。所以，从政治上讲，在他们的网站上实现OCSP装订并为互联网的另一种信任机制工作是一个坏主意。
我读过的关于证书撤销和保护用户的方法的最好的论文在这里：https://arstechnica.com/information-technology/2017/07/https-certificate-revocation-is-broken-and-its-time-for-some-new-tools/

可能是因为它在响应时节省了一些字节。
Alexandria 的答案（尤其是粗体部分）可能对google.com是正确的，但对facebook则不然。
在每个TLS连接中存在的OCSP装订响应占用了许多字节。如果响应中不存在装订的OCSP，会发生什么？客户端会向原始服务器发送OCSP验证请求，并将响应缓存几天。对于像google和facebook这样的热门网站，用户每天访问页面多次，并且通常OCSP响应被缓存在客户端，并且不需要额外的OCSP请求（例如，只有2%的客户端需要实际的OCSP请求）。
因此，对于这些流行的网站，删除OCSP装订（并为98%的请求节省100字节）比为2%的请求提高网站速度更好。