Running a Certificate Transparency log

原始链接: https://words.filippo.io/run-sunlight/

Certificate Transparency (CT) is crucial for web security, ensuring Certificate Authorities are honest and website owners are notified of unauthorized certificates. The problem is the number of independent CT log operators is too low. You can help! With the new Static CT API and the Sunlight implementation, running a CT log is now cheaper and easier. Static CT uses static files served from S3 or a CDN. Geomys operates a pro-bono log for $10k/year, but it could be done cheaper. Requirements: one server (redundancy optional), basic CPU/memory (ECC memory!), 2-3 Gbps outbound bandwidth, and 3-5 TB of storage (SSD or object storage). You also need at least two people. The priority is data durability. Monitor CT policies, update the implementation, and rotate log shards annually. Plan to operate for at least three years. Sunlight simplifies setup, and the community is welcoming. Contact the author or relevant forums for questions. It will be a huge contribution to internet security and brag-worthy.

这个 Hacker News 线程讨论了 Filippo.io 关于运行证书透明度 (CT) 日志的提案。主要内容包括: * **简化的实现:** “Sunlight” 和 “static-ct-api” 提供了一种比传统数据库驱动的 CT 日志更简单、更经济高效的替代方案,后者由于复杂性和高运营成本而面临失败。 * **存储责任:** 有人讨论 CT 日志服务器是否应该独自负责存储。一个提案建议 CA 可以存储日志数据直到其最新的条目,从而分担存储负担并可能提高冗余性。 * **审计和信任:** 讨论了对 CA 系统进行审计的必要性,以及 TLS 是否应该负责建立信任和身份,有人建议由第三方更好地管理信任。 * **谷歌联系问题:** 有人指出联系谷歌员工,特别是对于非付费客户来说,非常困难。 最初被删除的原文现在已经恢复。总的来说,讨论围绕着提高 CT 日志的效率、可靠性和可访问性。
相关文章

原文

Hear me out. If you are an organization with some spare storage and bandwidth, or an engineer looking to justify an overprovisioned homelab, you should consider running a Certificate Transparency log. It’s cheaper, easier, and more important than you might think.

Certificate Transparency (CT) is one of the technologies that underpin the security of the whole web. It keeps Certificate Authorities honest, and allows website owners to be notified of unauthorized certificate issuance. It’s a big part of how the WebPKI went from the punchline of “weakest link” jokes to the robust foundation of the security of most of digital life… in less than fifteen years!

CT is an intrinsically distributed system: CAs must submit each certificate to two CT logs operated by third parties and trusted by the browsers. This list is, and has been for a couple years, uncomfortably short. There just aren’t as many independent log operators as we’d like. Operating a log right now would be an immense contribution to the security of virtually every Internet user.

It also comes with the bragging rights to claim that your public key is on billions of devices.

Where’s the catch? Well, until recently running a log was a pain, and expensive. I am writing this because as of a few months ago, this has changed!

The Sunlight logo, a bench under a tree in stylized black ink, cast against a large yellow sun, with the text Sunlight underneath

Browsers now accept CT logs that implement the new Static CT API, which I designed and productionized in collaboration with Let’s Encrypt and the rest of the WebPKI community over the past year and a half. The key difference is that it makes it possible to serve the read path of a CT log exclusively through static, S3 and CDN friendly files.

Moreover, the new Sunlight implementation, sponsored by Let’s Encrypt, implements the write path with minimal dependencies and requirements. It can upload the Static CT assets directly to object storage, or store them on any POSIX filesystem.

You can learn more if you are curious in Let’s Encrypt’s retrospective, in the original Sunlight design document, or in the summarized public announcement.

Geomys, my open source maintenance firm, operates a pro-bono Sunlight-backed trusted Static CT log for $10k/year, including hardware amortization, colocation, and bandwidth. I’m sure it can be done for cheaper.

Ok, so what does it take to run a CT log in 2025?

  • Servers: one. No need to make the log a distributed system, CT itself is a distributed system.
  • If you want to offer redundancy you can run multiple logs.
  • The uptime target is 99% over three months, which allows for nearly 22h of downtime. That’s more than three motherboard failures per month.
  • CPU and memory: whatever, as long as it’s ECC memory. Four cores and 2 GB will do.
  • Bandwidth: 2 – 3 Gbps outbound.
  • Storage: you have two options.

  • 3 – 5 TB of usable redundant filesystem space on SSDs.

  • 3 – 5 TB of S3-compatible object storage, and 200 GB of cache on SSD.

Static CT logs are just flat static files, which you can serve with any HTTP server from disk, or expose as a public object storage bucket.

  • People: at least two. The Google policy requires two contacts, and generally who wants to carry a pager alone.

That’s pretty much it!

Durability is the first priority: it’s really important that you never lose data once it’s fsync’ed to disk or PUT to object storage, since your log will have signed and returned SCTs, which are promises to serve the certificates it received. This means for example that backups are useless: they would rollback the log’s state.

In terms of ongoing effort, a log operator is expected to read the Google and Apple CT Log policies, monitor the [email protected] mailing list, update the log implementation from time to time, and rotate log temporal shards every year. (For example, we just stood up 2027 shards of our log.)

Given the logs lifecycle, you should plan to stick around for at least three years.

Sign me up!

If you want to become a CT log operator, first of all… thank you!

The Sunlight README was rewritten recently to get you up and running easily. Sunlight is highly specialized for Certificate Transparency and the WebPKI, and it’s designed to help you operate a healthy, useful CT log with minimal configuration.

The community is eager to welcome new log operators. You can post questions, reports, and updates on the transparency.dev Slack, ct-policy mailing list, or Sunlight issue tracker. I encourage you to reach out even just to share your plans, or to ask any questions you might have before committing to running a log.

You might also want to follow me on Bluesky at @filippo.abyssdomain.expert or on Mastodon at @[email protected].

The picture

I systematically make the mistake of reaching a beautiful spot with my motorcycle, watching the sunset, and then realizing “oh, shoot, now it’s dark!” This time, the motorcycle didn’t start, too, and it was the first ride of the season in January. Got to read A Tour of WebAuthn by Adam Langley, though, so who can say if it was good or bad.

An e-ink tablet rests on a wooden table in the foreground, with a motorcycle parked on a roadside in the background along a mountain road against a beautiful sunset with haze and scattered clouds.

Geomys, my Go open source maintenance organization, is funded by Smallstep, Ava Labs, Teleport, Tailscale, and Sentry. Through our retainer contracts they ensure the sustainability and reliability of our open source maintenance work and get a direct line to my expertise and that of the other Geomys maintainers. (Learn more in the Geomys announcement.)

Here are a few words from some of them!

Teleport — For the past five years, attacks and compromises have been shifting from traditional malware and security breaches to identifying and compromising valid user accounts and credentials with social engineering, credential theft, or phishing. Teleport Identity is designed to eliminate weak access patterns through access monitoring, minimize attack surface with access requests, and purge unused permissions via mandatory access reviews.

Ava Labs — We at Ava Labs, maintainer of AvalancheGo (the most widely used client for interacting with the Avalanche Network), believe the sustainable maintenance and development of open source cryptographic protocols is critical to the broad adoption of blockchain technology. We are proud to support this necessary and impactful work through our ongoing sponsorship of Filippo and his team.

联系我们 contact @ memedata.com