Certstream is a service that aggregates certificates from Certificate Transparency logs and streams them in real-time. It provides a firehose of newly issued SSL/TLS certificates that developers can filter and process.

What protocols does certstream-server-rust support?

certstream-server-rust supports WebSocket and Server-Sent Events (SSE), and ingests from both RFC 6962 and static-CT-API (checkpoint + tile) logs. This allows integration with browsers, command-line tools, and data pipelines.

How do I connect to the certstream API?

Self-host with Docker, then connect to ws://localhost:8080/ via WebSocket, or use `curl -N http://localhost:8080/sse` for Server-Sent Events. Python users can use the certstream library: certstream.listen_for_events(callback, url='ws://localhost:8080/'). See the Quick Start guide for details.

What can I use the certstream API for?

Common use cases: phishing domain detection, brand monitoring, security research, threat intelligence, certificate inventory, and discovering newly registered domains. The certstream API streams every newly issued SSL/TLS certificate in real-time from Certificate Transparency logs.

Certificate transparency · streamed

Real-time CT log streaming, built in Rust.

Name: certstream-server-rust
Author: reloading01

A drop-in certstream server that aggregates newly issued SSL/TLS certificates from every Chrome- and Apple-trusted Certificate Transparency log and streams them over WebSocket and SSE. RFC 6962 and static-CT-API, in a single binary.

v1.5.6·MIT· RFC 6962·static-CT-API· WebSocket & SSE·single binary

Quick Start View on GitHub

docker run -d -p 8080:8080 ghcr.io/reloading01/certstream-server-rust:latest

What you get

Everything a CT monitor needs, nothing it doesn't.

Built for security teams, researchers, and developers who need reliable Certificate Transparency monitoring.

Multi-protocol streaming

WebSocket and Server-Sent Events. WebSocket for real-time clients, SSE for browsers and pipelines — same data, your choice of transport.

RFC 6962 + static-CT-API

Both the classic get-entries protocol and the new checkpoint + tile static-ct-api logs are watched side by side in one process.

Cross-log deduplication

The same certificate shows up across many logs. A SHA-256 filter collapses duplicates so each client sees a clean, single stream.

State persistence

Resume from the last processed position after a restart. No certificate loss during maintenance or upgrades.

Connection limiting

Per-IP and total connection caps. Production-ready protection against abuse and runaway clients.

Token authentication

Bearer-token access control with constant-time comparison. Multiple tokens, configurable header name.

Hot-reload config

Configuration changes apply without a restart. A file watcher picks up edits for zero-downtime tuning.

Circuit breaker & health

Automatic retry with exponential backoff and per-log circuit breaking. Failing logs are isolated, not allowed to spam.

Metrics & REST API

A Prometheus /metrics endpoint plus an optional REST API for server stats, log health, and certificate lookup.

Coming from the original

Point your client at a new address.

The wire format is the one Calidog's certstream-server established and certstream-server-go kept, so existing clients work unchanged.

                            Python
                            certstream library
                        

import certstream

certstream.listen_for_events(callback,
    url='wss://your-host:8080/')

                            Anything else
                            plain WebSocket
                        

# same certificate_update messages,
# same all_domains, same leaf_cert
wscat -c wss://your-host:8080/

Message types, field names and the leaf_cert shape are unchanged, so parsers written against either predecessor keep working. What you gain is coverage and cost: the tile-based static-CT-API logs that now carry most issuance, cross-log deduplication so the same certificate does not arrive three times, and the resource profile above. If you only want hostnames, the /domains-only stream cuts about 4 KB per certificate down to roughly 200 bytes.

Performance

Measured, not marketed.

All 45 Chrome- and Apple-trusted logs, default configuration, one subscriber on the domains-only stream. Sampled every 30 seconds over two hours.

420/s

Certificates ingested, median · 796/s at p95

722/s

Domain names · 62 million a day

80MB

Resident memory, steady state · 50 MB live heap

0.2core

CPU, median · 0.18 at p95

That is 36 million certificates a day on a fifth of one core. Each certificate is serialized once and broadcast to every subscriber through an Arc<PreSerializedMessage> with zero-copy text frames; when nobody is connected, serialization is skipped outright. Memory is flat rather than merely bounded, and the reasoning behind that number is written up in 358 MB resident, 52 MB in use.

Engineering notes

What running this against every trusted log taught me.

I blamed HTTP/2 multiplexing. Then I counted the connections.

Every request succeeded. The log stayed 33,000 entries behind. The mechanism I blamed was real, present, and not the problem.

The CT logs that serve tiles but publish no checkpoint

Three logs, zero errors, 279,000 entries behind. The fast way to read them was sitting right there, behind a missing file.

358 MB resident, 52 MB in use: where the rest went

A service that looked like it was leaking. It wasn't, and the fix was five settings the allocator had been running without.

All posts

Support the project

Built in spare time, kept free.

I build this in my free time. Just using it, starring the repo, or sharing it with someone who needs it already means a lot — that's the kind of thing that keeps me going.

If you'd like to go a step further, you can sponsor me on GitHub. No pressure though — every form of support is appreciated.

Sponsor on GitHub