# Certificate Transparency Monitoring is now generally available

[Cloudflare](https://yomu.fyi/company/cloudflare) · Jenny Yang · Aug 13, 2026

**Type:** Problem & solution

## Summary

Cloudflare announced the general availability of Certificate Transparency Monitoring alongside a filtering mechanism to eliminate noisy alert emails. Previously, the monitoring system alerted domain owners for all Certificate Transparency log entries, including routine, automated renewals for Universal SSL, Advanced Certificate Manager, and backup certificates. Because the alerting flow and certificate ordering service operated independently, existing identifiers like TBSCertificate hashes arrived too late to verify pre-certificates. To resolve this race condition, the ordering service now computes an SHA-256 hash of the DER-encoded SubjectPublicKeyInfo structure at key generation. When the alerting service discovers a log entry, it recomputes this hash to verify ownership against the ordering database, suppressing alerts for Cloudflare-managed certificates while preserving alerts for external or unexpected issuances.

## Context

Cloudflare's Certificate Transparency Monitoring previously generated alert emails for every TLS certificate appearing in public CT logs across more than 650,000 domains. Because Cloudflare frequently issues routine certificates such as Universal SSL renewals and backup certificates, users received excessive notifications that obscured genuinely suspicious certificates. Additionally, the certificate ordering service and the CT alerting service operated independently, preventing the alerting pipeline from immediately identifying whether an observed certificate originated from Cloudflare's internal systems.

## Approach / What changed

Cloudflare solved the alerting race condition by using the public key inside the SubjectPublicKeyInfo (SPKI) structure as a shared identifier. The certificate ordering service computes an SHA-256 hash of the DER-encoded SPKI (spki\_sha256) straight from the Certificate Signing Request at key generation before issuance begins. When the CT alerting service parses a log entry for a pre-certificate or final certificate, it independently computes the same SPKI hash and checks the ordering database, suppressing alerts for matching Cloudflare-managed records while still alerting on unrecognized or externally issued certificates.

## Takeaways

- Using the stripped fingerprint of the TBSCertificate failed as a deduplication key between services because it is unavailable to the ordering service during the pre-certificate stage.
- The SHA-256 hash of the DER-encoded SubjectPublicKeyInfo structure remains constant, unique, and reproducible across Certificate Signing Requests, pre-certificates, and final certificates.
- Suppressing alerts via SPKI matching silences routine renewals and abandoned pre-certificates generated by Cloudflare while preserving alerts for user-uploaded custom certificates and external issuances.

**Tags:** [Architecture](https://yomu.fyi/topic/architecture), [Monitoring](https://yomu.fyi/topic/monitoring), [Observability](https://yomu.fyi/topic/observability), [Reliability](https://yomu.fyi/topic/reliability)

[Read original post](https://blog.cloudflare.com/certificate-transparency-monitoring-ga)