猜测：行不通。当一些 CA 尝试使用非标准的修订方案时也是如此。-- 这只是在实际发布另一个证书时提交一个证书的特定变体。这是由实际上费心检查的浏览器检测到的。->我的网站启用了证书透明度，但 Chrome 仍显示 NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED

-- CT 执行取决于浏览器。而 AFAIK 只有 Chrome 才需要 Symantec 证书。但 2017 年 10 月 Chrome 的 CT-everything 要求即将到来。请参阅：https ://groups.google.com/a/chromium.org/forum/m/#!topic/ct-policy/78N3SMcqUGw

编辑1：CT有什么用？

你写了：

CT 的真正目的是防止 CA 为其不应颁发证书。

不是。目标不是预防，而是问责。CA 可以随时为任何域颁发证书。CT 不会更改该部分。

改变游戏规则的是，当颁发流氓证书时，可能会发生以下两种情况之一：

• 如果 CA 根本不提交给 CT 或使用不同的主机名提交，那么（一旦浏览器实际执行此操作）浏览器将拒绝证书。流氓证书将毫无用处。
• 如果 CA 确实使用正确的主机名提交给 CT，那么证书将是公开的。并且关心的域所有者可能会在 CT 日志中为他的所有域名放置一个自动监视作业。（Facebook 免费提供这样的服务。）

用他们自己的话来说：

Certificate Transparency 可以检测由证书颁发机构错误颁发或从其他无可指责的证书颁发机构恶意获取的 SSL 证书。它还可以识别出流氓行为并恶意颁发证书的证书颁发机构。

是的，有可能捕捉到您描述的场景。

这之所以成为可能，是因为整个证书链都存储在日志中。那么问题是“哪一方有责任这样做？” “他们是怎么做到的？”

在我看来，主要责任是客户作为依赖方（我的解释，标准中没有说明），在依赖任何东西之前进行适当的检查。

我的重建（解释？）它是如何发生的 - 基于RFC 6962 文档：

1. 证书（预证书和实际证书）按照您的描述记录和颁发。
2. 在 TLS 握手期间，客户端包含一个 ClientHello 扩展“signed_certificate_timestamp”，其中 extension_data 为空。
3. 服务器在 extension_data 中返回类型为“signed_certificate_timestamp”的 SCT（多个，来自多个日志提供程序，如果适用）。
4. 客户端从日志中检索证书链，并以任意顺序执行 4 次检查。
5. (3a) 服务器提供的证书与日志提供的证书之间的证书签名是否匹配？
6. (3b) 证书 SCT 是否匹配？（检索似乎是通过 LogID，所以我想这个检查是必需的）
7. (3c) 证书完整性检查吗？这已经是已经流行的检查的一部分。
8. (3d) 服务器名称是否与证书中的 SNI/SN 条目之一匹配？这也已经是当前流行的检查的一部分。

我预计如果客户执行 3a 和 3b，欺诈将会被抓住。CT 日志和 SCT 的作用在于向客户（包括证书所有者和 CT 审核员）提供信息，以便及早发现此类欺诈行为。

如果证书所有者在您描述的场景中没有同谋，则只要将证书交付给所有者并且所有者将证书提交到 CT 日志，就会检测到问题。证书上会有签名不匹配。

即使证书所有者是同谋，当兼容的浏览器（客户端）进行此检查时，它也会在 3a 或 3b 中被捕获，具体取决于证书上数据的更改方式。