首先，是什么阻止了我设置自己的日志、制作 SCT 并且永远不会告诉 Google 或其他任何人？

没有什么。

浏览器能否判断日志是否合法？

它在 RFC 中未指定：

TLS 客户端 [...] 应通过 [...] 使用相应日志的公钥来验证 SCT。请注意，本文档没有描述客户端如何获取日志的公钥。

（注意：这句话已从当前正在开发的新 RFC 第 5.3 节中删除。我不知道他们是否将其替换为更具体的内容）

但是，例如 Chrome，默认情况下只会信任少数硬编码的日志：

默认情况下，Chrome 会检查来自 Chrome 识别的预定义 CT 日志列表的 SCT。

.

浏览器或其 Auditor 组件是否将 SCT 发送到 Monitors？
[...] 具体来说，浏览器（审核员）如何知道要与哪些监视器交谈？

这取决于。根据Gossip RFC 草案，这将是受信任的审计员关系类型的八卦。（这是提出的 3 种八卦中的一种。所有这些机制都可以并行使用。）

RFC 草案继续说：

受信任的审核员关系预计将是最稀有的八卦机制，因为 HTTPS 客户端正在向第三方提供其浏览历史记录的纯正报告。虽然这样做有正当和普遍的理由，但在没有征得用户知情同意的情况下，没有适当的方法可以建立这种关系。

所以我想它要么是手动配置的，要么是配置为来自某个受信任的一方（我猜是浏览器制造商）。

###Update 2018-01-26Fri.：@__agwa-Blog。最近有一篇关于这个主题的博客文章：

• Andrew Ayer，2018-01-10，实践中如何审核证书透明度日志？（存档在这里。）

这是一本深入的技术读物。TLDR 是这里的最后一段：

这一切都是一条路。CTv2 还没有标准化。Chrome 仍然不进行任何 SCT 审计，因此其 CT 政策要求至少有一个 SCT 来自 Google 操作的日志，因为 Google 显然相信自己的日志不会违背其承诺。幸运的是，即使没有广泛的日志审计，Certificate Transparency 也取得了巨大的成功，清理了证书颁发机构生态系统，让每个人都更加安全。尽管如此，我认为如果证书透明度的可审计性从未完全实现，那将是一种耻辱，我希望我们能够找到一种方法让它发挥作用。

• 首先，是什么阻止了我设置自己的日志、制作 SCT 并且永远不会告诉 Google 或其他任何人？

查看文档似乎这是解决该问题的要求：

从您引用的页面中：“每个证书日志都必须公开宣传其 URL 和公钥（除其他外）。任何人都可以通过 HTTPS GET 和 POST 消息与日志进行交互。”

监视器正在捕获这些日志的状态，并确保它们与其历史记录一致。据推测，如果审计员不知道日志，它会立即将其与浏览器相关联[更多内容见下文]。

• 浏览器能否判断日志是否合法？
• 浏览器或其 Auditor 组件是否将 SCT 发送到 Monitors？

同样，从您引用的页面中：“大多数审核员可能会内置在浏览器中。在此配置中，浏览器会定期向其集成审核组件发送一批 SCT，并询问是否已将 SCT（和相应的证书）合法添加到日志。然后审核员可以异步联系日志并执行验证。

如果您尝试创建自己的日志或损坏它，监视器将能够检测到这一点。我对上面的“定期”一词有点不确定。我不确定我是否理解批处理或 SCT。这是否意味着浏览器会认为 SCT 是好的，直到他们被告知其他情况？这对我来说似乎是一个洞。我认为您希望在提交任何新证书时立即对其进行验证。