这些要求之一在第4.9.9节中必须带有MUST标记：
OCSP（在线证书状态协议）响应必须符合RFC 6960和/或RFC5019。OCSP响应必须：
- 由签发其吊销状态正在检查的证书的CA签名，或者
- 具有签名OCSP响应程序，其证书由发布证书的CA签名，并检查其吊销状态
在后一种情况下，OCSP证书签名必须包含RFC 6960中指定的id-pkix-ocsp-nocheck类型的扩展。
几乎所有的证书颁发机构（CA）都违反了此规则，从而产生了一些后果。
这是“公共信任证书的颁发和管理基准要求”（最新版本1.7.0，2020年5月4日，pdf）中的屏幕截图：
4.2.2.2节中的RFC6960标准通过id-kp-的存在定义了“ OCSP委托响应者” OCSP签名。
开发人员Ryan Sleevi的公司专门研究证书，他证明CA严重违反了规则4.9.9。
在检查了crt.sh数据之后，Ryan Slavy发现了293个中间证书，但没有pkix-nocheck扩展名，其中180个当前有效且113个被吊销。
在Census.io上进行筛选会颁发276个证书符合这些条件。
因此，这些证书违反了CA / Browser的基本要求，此外还违反了强制性要求。
根据Ryan Slavy的说法，CA应该仔细查看CA /浏览器规则。一些CA可能不熟悉RFC 6960的要求。
缺少相应的扩展名不只是一种形式。这里有没有问题在这个意义上的中间CA无法从同一个根CA吊销另一个中间CA证书
真正的问题是，在没有扩展的情况下，中间CA在理论上可以取消证书的吊销另一个中间CA或根CA本身。这确实是一个问题。实际上，在这种情况下，证书颁发机构没有可靠的选择来完全和不可撤销地撤消证书。吊销过程无法按预期方式进行，这为可能发起攻击以恢复吊销证书的攻击者打开了大门。
若要解决此问题，建议在吊销证书时，永久删除密钥的所有副本，以使吊销也变得不可逆。
为了证明CA的合理性，我们可以说即使没有此缺点，证书吊销过程也无法按预期工作。例如，主要的浏览器维护自己的CRL副本-并不总是检查它们是否为最新。这些CRL仅包含基本，最重要的信息，但还远远不够完整。例如，Chrome不会检查每个特定的TLS证书是否已被吊销，而Firefox会检查。也就是说，有时使用Chrome浏览器，您可以安全地访问证书过期的站点，而Firefox会发出警告，并且不允许您进入该站点。
有趣的是，根据规则，必须在7天内在浏览器中吊销不正确的证书，但是在这种情况下例外。 Mozilla的Ben Wilson说他们不会吊销缺少id-pkix-ocsp-nocheck扩展名的证书。尽管此类证书不兼容，但是Firefox浏览器不受此特定安全漏洞的影响，因为它不接受由中间CA签名的OCSP响应。
CA应该以某种方式替换不正确的证书，但是没有最终期限。
有关企业PKI解决方案的更多信息，请联系GlobalSign经理+7（499）678 2210，sales-ru@globalsign.com。