我注意到至少有一个主要的 CA（Comodo）通过 HTTP 而不是 HTTPS 发布他们的 CRL。
在我看来，这似乎是一个漏洞，因为攻击者可以劫持寻求下载 CRL 的 HTTP 连接，并且在使用HSTS时至少执行有效地相当于对域进行 DoS 攻击的操作。（由于 HSTS 处于活动状态，浏览器不应允许用户绕过无效证书警告；请参阅 RFC 6797第 8.4节和第 12.1 节。）
虽然CRL 通常是已签名的，而且似乎任何理智的实现都应该拒绝未通过签名验证的已签名 CRL，但我还没有看到任何方法可以在任何 Web 浏览器中确定 CRL 的签名者，因此即使签署替换使用您自己的根证书密钥的 CRL似乎是一种风险相对较低的操作。当然，这假设浏览器要求首先签署 CRL；如果没有，您可以将其替换为未签名的 CRL。（当然，如果实现 拒绝签名验证失败的已签名 CRL，甚至是未签名 CRL，欺骗 UA 使用已被吊销但尚未达到其到期日期的证书变得微不足道。）
这是一个实际的潜在问题吗？UA 通常会针对 CRL 执行哪些检查以防止其成为实际问题？
不存在未签名的 CRL 之类的东西；签名字段是强制性的，任何使用 CRL 的系统都会验证签名。
在纯 X.509中，如果 CRL 由“允许的撤销颁发者”签名，则 CRL 将被视为“可接受”作为有关给定证书E的撤销状态的信息来源：CRL 的签名必须与包含在已验证的证书，其subjectDN等于EissuerDN的（如果E包含相关的 CRL 分发点扩展并且CRL 具有匹配的颁发者分发点扩展，则您可以拥有不同的 DN ；但让我们忘记这个额外的复杂性）。完整的规则在第 6.3 节中公开. 请注意，“纯 X.509”应该在目录的上下文中工作，目录是一种全球 LDAP 服务器，它以明确的专有名称引用所有内容。
由于目录并没有真正起作用，因为它根本不存在，现有的实现倾向于实现更严格和更简单的规则。一般而言，验证CA C颁发的证书E的 Web 浏览器将接受一个 CRL，前提是它也由同一个 CA 使用相同的密钥签名。此规则使路径验证保持简单和有界（否则，您可能会想象这样一种情况，您必须为路径中的每个证书获取一个 CRL，并且每个 CRL 都将针对另一个需要其自己的路径验证的 CRL 颁发者证书进行验证，因此在）。因此，相对于您自己的根 CA 生成您自己的 CRL 不太可能产生任何实际效果。
因此，CRL 与证书一样，是始终签名的对象，并且在没有验证签名 (*) 的情况下永远不会使用，因此它们可以通过纯 HTTP 提供服务。使用 HTTPS 服务 CRL 只是浪费资源；它甚至可能阻止 CRL 下载工作，因为某些实现（例如 Windows）在验证证书时拒绝遵循 HTTPS URL（无论是用于 CRL、OCSP 还是额外的中间 CA 下载），因为这意味着 SSL，然后是另一个要验证的证书，并且可能是一个无限循环。
(*) 我在这里排除根 CA“证书”，传统上是自签名的；这些不是X.509 意义上的真正证书，而只是模仿证书编码规则的对象。
关于重放攻击，CRL 带有生成日期和下一次更新日期的时间戳。nextUpdate 日期在 PKIX 配置文件中是强制性的。如果证书被吊销，则在使用不安全通道之前可以重播旧的 CRL。nextUpdate
我想补充一点，一些（至少）Mozilla 浏览器有一个配置变量：security.OCSP.require（请参阅 IRL about:config），默认情况下设置为 false。
似乎如果 security.OCSP.require 设置为“false”，浏览器应该回退到在命名的 CRL 分发点 URI 处验证 CRL，巧合的是，这与授权信息访问字段中使用的相同 URI 可能是签名将找到 CA 和 CRL。
根据经验（至少在 Linux 中），如果此 URL 被阻止，至少 Mozilla 浏览器（Firefox、Sea Monkey、Chrome）将通过证书而无需验证它是否已被撤销和替换。
我很难理解这不是一个漏洞，但这不是原始问题的症结所在。
仅供参考：在 Windows 中，CRL 和 OCSP 设置似乎是组策略（本地计算机策略、计算机配置、Windows 设置、安全设置、公钥策略）的功能，并且可以配置，但至少在 Windows 2003 中没有'似乎没有默认配置。在 Mac 上，对于那些倾向于使用密码信任第三方的人来说，Keychain 可以进一步缓解这种情况......