你应该运行一个证书透明度日志

听我说。如果你是一个拥有闲置存储和带宽的组织，或者是一位想要合理利用过度配置家庭实验室的工程师，你应该考虑运行一个证书透明度日志。这比你想像的更便宜、更容易，也更重要。

证书透明度（CT）是支撑整个Web安全的技术之一。它能确保证书颁发机构（CA）诚实行事，并允许网站所有者收到未经授权证书颁发的通知。在不到十五年的时间里，CT技术帮助Web公钥基础设施（WebPKI）从"最薄弱环节"的笑柄变成了数字生活安全的坚实基础！

CT本质上是一个分布式系统：CA必须将每个证书提交到由第三方运营且受浏览器信任的两个CT日志。目前可信日志列表数量令人不安地稀少，独立日志运营者的数量远未达到理想水平。现在运营日志将对几乎所有互联网用户的安全做出巨大贡献。

此外，你还可以自豪地声称你的公钥存在于数十亿设备上。

那么有什么困难呢？直到最近，运行日志还是一件痛苦且昂贵的事情。我写这篇文章是因为几个月前，这种情况已经改变了！

新技术突破

浏览器现在接受实现新静态CT API的CT日志，这是我在过去一年半与Let’s Encrypt和WebPKI社区合作设计和投产的。关键区别在于，它使得CT日志的读取路径可以完全通过静态的、兼容S3和CDN的文件来提供服务。

此外，由Let’s Encrypt赞助的新Sunlight实现以最小的依赖和要求实现了写入路径。它可以直接将静态CT资源上传到对象存储，或将其存储在任何POSIX文件系统上。

如果你好奇，可以在Let’s Encrypt的回顾文章、原始Sunlight设计文档或总结性公开公告中了解更多信息。

我的开源维护公司Geomys运营着一个基于Sunlight的可信静态CT日志，每年成本为1万美元，包括硬件折旧、托管和带宽。我相信还可以做得更便宜。

配置要求

那么，在2025年运行CT日志需要什么？

服务器：一台。不需要让日志成为分布式系统，CT本身就是一个分布式系统。如果你想要提供冗余，可以运行多个日志。正常运行时间目标是在三个月内达到99%，允许近22小时的停机时间。

CPU和内存：任意配置，只要它是ECC内存。四个核心和2 GB内存就足够了。

带宽：2 Gbps出站峰值容量（可以卸载到CDN）。

存储：你有两个选择：

• 3-5 TB可用冗余文件系统空间（SSD）
• 3-5 TB S3兼容对象存储，以及200 GB SSD缓存

静态CT日志只是平面静态文件，你可以使用任何HTTP服务器从磁盘提供服务，或作为公共对象存储桶公开。

人员：Google政策要求提供两名代表的电子邮件地址。正常运行时间目标足够宽松，可能只需要一个人在正常工作时间内工作。

差不多就是这样！

运营考虑

耐久性是首要任务：一旦数据通过fsync同步到磁盘或PUT到对象存储，就绝不能丢失数据，因为你的日志已经签名并返回了SCTs，这是服务接收到的证书的承诺。这意味着备份是无用的：它们会回滚日志状态。

在持续工作方面，日志运营者需要阅读Google和Apple的CT日志政策，监控ct-policy@chromium.org邮件列表，不时更新日志实现，并每年轮换日志时间分片。（例如，我们刚刚建立了2027年的日志分片。）

考虑到日志的生命周期，你应该计划至少运营三年时间。

开始行动

如果你想成为CT日志运营者，首先……谢谢你！

社区热切欢迎新的日志运营者。你可以在transparency.dev Slack、ct-policy邮件列表或Sunlight问题跟踪器上发布问题、报告和更新。我鼓励你即使只是分享计划，或在承诺运行日志前提出任何问题，也要主动联系。

技术说明

如果假设六个月的分片最多增长到20亿个条目（迄今为止最大为19.3亿），并且旧分片在过期一个月后被删除，配置像Tuscolo那样的ZFS上的Sunlight最多需要2.75 TB。然而，WebPKI一直在增长，较短寿命的证书将增加颁发率，但也会使轮换更有效。配置3 TB并在未来几年内有计划地增加到5 TB将是谨慎的做法。

这是一个保守的峰值容量估计。目前Tuscolo日志产生的平均带宽约为50Mbps/峰值250Mbps，但监控器相对较少。RFC 6962日志报告的数字约为1-2 Gbps。静态CT将带宽减少了近80%，但也使监控日志更加容易，这可能会增加需求。可验证索引有望在未来减少完整监控器的数量。

对象存储部分可能在HDD上运行。写入路径可能没问题，但读取路径需要服务大量随机访问的文件。也许需要大型SSD缓存层。

或者使用Sunlight专门的HTTP读取路径Skylight，它具有一系列良好的指标和健康检查。

是的，两个九。写入路径的可用性根本不是大问题：CA只会回退到其他日志。读取路径的可用性对于确保及时监控新条目很重要，但它只是一个简单的静态HTTP服务器。请注意，Google计划分开读取和写入端点的要求，并要求读取路径具有更高的可用性。

由于短期证书和/或后量子签名，未来的要求可能会增加，但生态系统非常清楚CT日志运营者的潜在负担，并且有许多提案来缓解它，例如Merkle Tree Certificates和Verifiable Indexes。我对解决这个问题持乐观态度，但即使无法解决，如果日志变得太大，你始终可以将日志设置为只读而不会破坏生态系统。