Cybersecurity glossary
What is Certificate Transparency?
Learn what Certificate Transparency is, how CT logs and signed certificate timestamps detect mis-issued TLS certificates, and how domain owners monitor issuance for their names.
Definition
Certificate Transparency (CT) is an open framework of append-only public logs that record issued TLS certificates, enabling domain owners and the ecosystem to detect mis-issuance and improve accountability of publicly trusted Certificate Authorities.
Why Certificate Transparency matters
Public Certificate Authorities can issue trusted certificates for names they validate. That power is necessary for HTTPS scalability, and dangerous when validation fails or an attacker abuses issuance. Before Certificate Transparency, a fraudulent certificate could be used quietly against targeted users without the legitimate domain owner noticing.
Certificate Transparency (CT) makes issuance observable. Certificates from publicly trusted CAs are submitted to append-only logs. Domain owners, browsers, and researchers can monitor those logs for surprises: unknown issuers, unexpected wildcards, or certificates for hostnames that should not exist.
CT does not replace careful CA operations. It adds sunlight.
How Certificate Transparency works
CT introduces public logs, cryptographic inclusion proofs, and client-side expectations that certificates were logged.
CA issues a certificate
A publicly trusted CA validates the applicant and creates an X.509 certificate for requested names.
Submit to CT logs
The certificate—or a precertificate—is submitted to multiple qualified CT logs.
Receive SCTs
Logs return Signed Certificate Timestamps promising inclusion in the append-only log.
Deliver SCTs to clients
SCTs are embedded in the certificate, provided via TLS extension, or OCSP—depending on deployment era and CA practice.
Browsers enforce policy
Major browsers require adequate CT evidence for publicly trusted certificates to be considered valid.
Owners monitor names
Monitoring services watch logs for certificates matching domains you care about and raise alerts.
Because logs are append-only and publicly auditable, rewriting history to hide a mis-issued certificate is designed to be detectable.
Core CT building blocks
CT logs
Independent append-only ledgers operated under ecosystem policies, storing issued certificate data for public inspection.
SCTs
Signed Certificate Timestamps that serve as early evidence a log accepted a certificate for inclusion.
Monitors
Services that watch logs for certificates affecting specific domains and notify owners of anomalies.
Auditors
Checks that logs behave correctly, including consistency of the append-only Merkle tree history.
What CT is not
| Misconception | Reality |
|---|---|
| CT blocks all bad certificates automatically | CT reveals issuance; humans and processes still respond with revocation and distrust. |
| CT replaces domain validation | CAs must still validate control. CT helps detect when that process failed or was abused. |
| Self-signed certs need CT | Public CT policy targets publicly trusted certificates, not arbitrary private PKI. |
| One log entry equals safety | Browser policies typically expect multiple SCTs from qualified logs. |
Practical value for defenders
CT monitoring is one of the highest-signal controls for DNS and HTTPS ownership. If an attacker obtains a certificate for login.example.com from any public CA, monitors can alert even when the certificate is never installed on your CDN.
That visibility supports incident response: identify the CA, request revocation, investigate validation channels such as email or DNS records, and check whether traffic was redirected through attacker infrastructure.
CT also helps inventory discovery. Organizations often find forgotten subdomains and old brand names still receiving certificates long after projects ended.
Implementation checklist
- Use publicly trusted CAs that meet current CT requirements for internet-facing TLS.
- Monitor CT logs for all registered domains, critical subdomains, and wildcard patterns.
- Alert on unexpected issuers, unusual key algorithms, and names outside known inventory.
- Integrate CT alerts with certificate inventory and on-call response playbooks.
- Treat unexplained certificates as security incidents until proven benign.
- Keep DNS validation records and CA account credentials tightly controlled to reduce unauthorized issuance.
- Remember private mTLS CAs are separate; do not assume public CT covers internal issuance.
- Review historical CT data when assuming ownership of a newly acquired domain portfolio.
Relationship to Expect-CT
Expect-CT was an HTTP response header that asked browsers to enforce CT and report failures. Browser support has been removed or deprecated as CT enforcement became a baseline requirement for public certificates. New deployments should focus on compliant certificates and monitoring rather than Expect-CT headers.
The practical takeaway
Certificate Transparency records publicly trusted TLS certificates in open, append-only logs so mis-issuance can be detected and investigated. Browsers use SCTs to require logging; domain owners use monitors to watch their namespaces.
Deploy CT-compliant certificates, monitor your domains continuously, and respond quickly to unexpected issuance. Visibility does not revoke a bad certificate by itself—but without visibility, you may never know one exists.
Related security terms
Certificate Authority (CA)
Public CAs submit certificates to CT logs as part of modern Web PKI expectations.
X.509 Certificate
The issued credentials that appear in Certificate Transparency logs.
HTTPS
The user-facing protocol that depends on trustworthy TLS server certificates.
Expect-CT
A historical HTTP header related to CT enforcement signaling, now largely obsolete.
Frequently asked questions
What is Certificate Transparency in simple terms?
Certificate Transparency is a set of public logs where trusted TLS certificates are recorded. Anyone can watch those logs to see which certificates have been issued for a domain, making secret or mistaken issuance harder to hide.
What problem does CT solve?
CT helps detect mis-issued or unauthorized certificates. If a CA wrongly issues a certificate for your domain, CT monitoring can reveal it even if you never installed that certificate on your servers.
What is an SCT?
A Signed Certificate Timestamp is a promise from a CT log that a certificate has been accepted for logging. Browsers may require SCTs as evidence that public certificates were submitted to CT.
Do I need to configure CT on my web server?
Usually the CA embeds SCTs or provides them during issuance. Operators mainly need certificates from CT-compliant public CAs and should monitor logs for unexpected certificates covering their domains.
Does CT revoke bad certificates automatically?
No. CT provides visibility and accountability. Revocation, CA distrust, and incident response are separate actions taken after suspicious issuance is found.
Can private enterprise CA certificates appear in public CT logs?
Generally no. Public CT focuses on publicly trusted certificates. Private PKI certificates are not required to be logged in public CT and usually should not be.
How should organizations monitor CT?
Subscribe to CT monitoring for registered domains and wildcards, alert on unexpected issuers or names, and integrate findings into certificate inventory and incident processes.
References
Explore authoritative guidance and frameworks related to certificate transparency.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.