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

Certificate Transparency streaming, written in Rust.

Name: certstream-server-rust
Author: reloading01

Reads newly issued SSL/TLS certificates from Chrome- and Apple-trusted Certificate Transparency logs and streams them over WebSocket or Server-Sent Events. Both RFC 6962 and static-ct-api logs are supported, 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

Features

What the server does.

WebSocket and SSE

Certificate updates can be consumed over WebSocket or Server-Sent Events. Both transports carry the same certificate stream.

RFC 6962 and static-ct-api

The server watches both classic get-entries logs and newer static-ct-api logs based on checkpoints and tiles. Both types run in the same process.

Cross-log deduplication

The same certificate is often submitted to several CT logs. Certificates are deduplicated by SHA-256 before broadcast, so clients receive one update per certificate within the configured deduplication window.

State persistence

Watcher positions can be written to disk and restored after a restart, so each log does not start from scratch after a restart or upgrade.

Connection limits

Optional limits can be applied to the total connection count and per IP address.

Token authentication

Bearer-token authentication can be enabled for client connections. Tokens are compared in constant time, and multiple tokens and a custom header name are supported.

Configuration reload

The configuration file can be watched for changes, so supported settings can be updated without restarting the process.

Log health

Each CT log is tracked independently. Repeated failures move a watcher through healthy, degraded, and unhealthy, with retries and exponential backoff behind a per-log circuit breaker.

Metrics and REST API

Prometheus metrics are exposed at /metrics. An optional REST API serves server statistics, CT log status, and certificate lookup.

Compatibility

Existing certstream clients.

The certificate message format follows the one used by Calidog's certstream-server and certstream-server-go, so a client only needs a different WebSocket address.

                            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 a parser written against either predecessor keeps working. This implementation additionally reads static-ct-api logs and deduplicates certificates seen across several logs. If only domain names are needed, the /domains-only stream sends roughly 100 to 500 bytes per message instead of the 2 to 5 KB of the default stream.

Performance

Measured throughput.

A two-hour run against all 45 Chrome- and Apple-trusted logs, with the default configuration and one subscriber on the domains-only stream. Metrics were sampled every 30 seconds.

420/s

Certificates ingested, median. 796/s at p95

722/s

Domain names, 62 million a day

80MB

Resident memory, steady state. 50 MB allocated

0.2core

CPU, median

At the measured median that is about 36 million certificate updates a day. Each certificate is serialized once and shared with every subscriber through an Arc<PreSerializedMessage>, and serialization is skipped when no client is connected. The memory behaviour is described in 358 MB resident, 52 MB in use.

Blog

Engineering notes.

HTTP/2 multiplexing vs per-connection rate limits

Every request succeeded and the log stayed 33,000 entries behind. Switching transport gave me three connections instead of one, and changed nothing.

Reading Certificate Transparency tiles without a checkpoint

Three logs, zero errors, and 279,000 entries behind. The faster path was already there, behind an endpoint that returns 404.

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

Supporting the project.

certstream-server-rust is developed in my spare time and released under the MIT license. If you find it useful, starring the repository, reporting issues, or sharing it with someone who needs it is appreciated.

GitHub Sponsors is also available for anyone who wants to support development.

Sponsor on GitHub