Certificate Transparency

Certificate Transparency (CT) uses append-only public logs to make certificate issuance observable. Certificate authorities submit certificates or precertificates, and monitors and auditors inspect log evidence and consistency.

What it does well

• It makes certificate issuance publicly discoverable and supports independent monitoring.
• Merkle inclusion proofs and signed tree heads provide compact evidence about log state.
• It demonstrates how a community can combine log operators, monitors, and auditors around a shared transparency objective.

Trust, privacy, and operational model

The model involves certificate authorities, log operators, monitors, auditors, and clients with different responsibilities. Public logging is intentional: certificate names and related metadata may be visible. Privacy therefore comes from the certificate ecosystem's policies and redaction choices, not from hash-only submission.

Log consistency evidence helps detect equivocation, but CT does not by itself decide whether a certificate authority should have issued a particular certificate. Running or relying on CT requires log service, monitoring, and client-policy operations.

Difference from Witness

Witness timestamps arbitrary SHA-256 hashes through a configured witness quorum and exposes attestation and proof verification. CT is specialized for public certificate issuance transparency, with a different admission policy, audience, and privacy model. Witness's RFC 9162 log features are conceptually related to CT logs but do not make Witness a CT log or certificate-policy system.

When to use it instead

Use CT when the subject is TLS or certificate issuance and public observability, monitoring, and ecosystem compatibility are the requirements. Use a general timestamping system for arbitrary records instead.