Any of the publicly trusted certificate authorities can issue a certificate for your domain, and until Certificate Transparency you had no reliable way to know when one did. Certificate Transparency (CT) is a system of public, append-only logs that record every publicly trusted TLS certificate, so domain owners, browsers and researchers can see every certificate issued for a name. Browsers now refuse certificates that cannot prove they were logged. This guide explains how CT logs, Signed Certificate Timestamps and monitors work, what the Chrome and Apple policies require, and how security teams use CT to spot mis-issued certificates, phishing domains and shadow IT. It also covers the privacy side: CT publishes your hostnames too. It is for security operations, PKI and domain owners.
Key takeaways
- CT detects, it does not prevent: RFC 6962 says its aim is to make mis-issuance visible so affected parties can respond; you only benefit if someone watches the logs for your names.
- Browsers enforce it: Chrome and Apple platforms reject publicly trusted certificates that do not carry enough Signed Certificate Timestamps from independent logs.
- Monitoring is cheap and high value: searching or subscribing to CT for your domains finds unauthorised certificates, forgotten services and lookalike phishing domains.
- Every name you put in a public certificate becomes public: internal hostnames in public certificates are visible to attackers doing reconnaissance.
- The log ecosystem is changing: RFC 9162 (CT 2.0) exists, but deployed logs use RFC 6962 or the newer tiled Static CT API.
What it is
Certificate Transparency is a public audit trail for TLS certificates. When a CA issues a certificate that browsers will trust, it submits it to several independent logs. Each log returns a signed promise that the certificate will be added, and that promise travels with the certificate to the browser. Anyone can read the logs, so the owner of example.com can list every certificate issued for example.com by any CA in the world.
CT was designed at Google and published as RFC 6962 in June 2013, an Experimental RFC. It was a response to CA compromises and mis-issuance, where the first sign of a fraudulent certificate was usually its use in an attack. RFC 9162 (December 2021), "Certificate Transparency Version 2.0", obsoletes RFC 6962 on paper, but browser policies and production logs still use the version 1 formats. For how certificates and CAs work in general, see the PKI Basics Guide.
How it works
The actors
| Actor | Role | What it checks or produces |
|---|---|---|
| Certificate authority | Submits precertificates or certificates to logs | Collects SCTs and embeds them in the final certificate |
| Log | Append-only Merkle tree of certificates | Issues SCTs, publishes Signed Tree Heads (STHs), answers proof requests |
| Monitor | Watches logs for certificates of interest | Downloads entries, alerts domain owners, checks the log grows correctly |
| Auditor | Verifies log behaviour | Checks consistency proofs between tree heads and inclusion proofs for specific certificates |
| User agent (browser, OS) | Enforces CT policy | Rejects certificates without enough valid SCTs |
| Domain owner | Requests certificates and monitors its names | Investigates and revokes anything it did not authorise |
From issuance to the browser
- Precertificate: the CA validates the domain and builds a precertificate, which contains every field of the final certificate plus a critical "poison" extension (OID 1.3.6.1.4.1.11129.2.4.3) so no client will accept it as a real certificate. This solves a circular problem: the certificate must contain SCTs, but SCTs come from logging the certificate.
- Submission: the CA submits the precertificate to several logs (the
add-pre-chainendpoint). Logs only accept submissions that chain to a root they accept. - Signed Certificate Timestamp: each log returns an SCT: a version, the log ID (a SHA-256 hash of the log's public key), a millisecond timestamp and the log's signature. An SCT is a promise to add the entry within the log's Maximum Merge Delay (MMD), which certificate.transparency.dev describes as usually 24 hours.
- Final certificate: the CA embeds the SCTs in an X.509 extension (OID 1.3.6.1.4.1.11129.2.4.2) and issues the certificate. RFC 6962 also allows SCTs in a TLS extension (
signed_certificate_timestamp, type 18) or in a stapled OCSP response, but embedding needs no server changes and is by far the most common. - Browser check: during the TLS handshake the browser verifies the SCT signatures against its list of known logs and applies its CT policy. See the How TLS Works Guide for where this sits in the handshake.
Why the logs can be trusted
Each log is a Merkle tree: leaves are certificate entries, and each parent is a hash of its children (RFC 9162 uses prefixes 0x00 and 0x01 to separate leaf and node hashes). The log periodically signs the root hash, tree size and timestamp as a Signed Tree Head. An inclusion proof shows a given certificate is in the tree; a consistency proof shows that a newer tree head extends an older one without changing earlier entries. A log that dropped or rewrote entries would produce proofs that fail, and Chrome's log policy lists inconsistent STHs and failure to include a certificate for which an SCT was issued as grounds for removing a log.
Static CT API (tiled logs): the C2SP Static CT API keeps the RFC 6962 submission endpoints but serves the tree as static files: a signed /checkpoint, hash tiles of 256 entries under /tile/ and entry data under /tile/data/. Monitors fetch the tiles and compute proofs themselves, which is cheaper to cache and serve. Chrome's log policy accepts logs that conform to RFC 6962 or static-ct-api v1.1.0, and logs are temporally sharded, each accepting only certificates that expire within a set window.
Browser policies
| Requirement | Chrome CT policy | Apple CT policy |
|---|---|---|
| Embedded SCTs, lifetime 180 days or less | 2 SCTs from distinct logs | 2 SCTs from distinct logs |
| Embedded SCTs, longer lifetime | 3 SCTs (over 180 days) | 3 SCTs (181 to 398 days) |
| Operator diversity | At least two SCTs from distinct log operators | Cap on SCTs counted per operator (1 or 2 by lifetime) |
| SCTs via TLS extension | 2 SCTs from qualifying logs, distinct operators | 2 SCTs from currently approved logs |
| Other conditions | At least one SCT from a log Qualified, Usable or ReadOnly at check time; stapled OCSP SCTs accepted only before Chrome 148 | At least one SCT from an RFC 6962-compliant log |
| Result if not met | Certificate rejected | TLS connection fails in Safari and apps |
Chrome disables enforcement if its stored log list is more than 70 days old, so an unpatched browser stops enforcing. certificate.transparency.dev lists Chrome (from early 2015), Safari (2018) and Firefox (2025) among user agents that support CT. Private CAs, such as an internal Microsoft AD CS or a service mesh CA, are not subject to these policies and do not log.
Why it matters
- Mis-issuance detection: a certificate for your domain from a CA you do not use, or with names you never requested, is either a validation failure at the CA or an attacker who controlled DNS, email or a web path long enough to pass domain validation. CT is often the only place you will see it.
- Phishing and lookalike domains: attackers register lookalike domains (ATT&CK T1583.001) and obtain free certificates for them (T1588.004 Digital Certificates, T1608.003 Install Digital Certificate). Those certificates are logged at issuance, often before the phishing site goes live, so watching for your brand terms gives early warning. See the Typosquatting and Lookalike Domains Guide and the Phishing Guide.
- Asset discovery: CT shows certificates teams obtained without telling security, including staging, vendor-hosted and forgotten services, which feeds the external attack surface inventory.
- Attacker reconnaissance: the same data is public to adversaries, who search it to enumerate subdomains (T1596.003 Search Open Technical Databases: Digital Certificates). Assume anything in a public certificate is known.
- CA accountability: public logs let researchers and browsers find CAs that break the Baseline Requirements.
Monitoring CT for your organisation
Search versus monitor: search tools such as crt.sh let you query logs ad hoc by domain (use %.example.com to include subdomains). Monitoring services watch new entries and alert you; certificate.transparency.dev lists community-submitted options including CA, CDN and independent services, and some entries are search tools rather than continuous monitors. Large organisations sometimes run their own monitor against the logs' APIs or static tiles; most should subscribe to a service and feed alerts into the SOC.
- List what to watch: every registered domain, plus brand keywords and common misspellings for lookalike detection.
- Baseline: pull current certificates for each domain from CT and record the CAs, the account or ACME client that requested each, and the owner.
- Define expected issuance: approved CAs (also published in DNS CAA records, RFC 8659, which tell CAs who may issue), approved certificate types and expected naming.
- Alert on deviation: new certificates from an unapproved CA, names outside the expected pattern, wildcards where policy forbids them and any certificate with CA capability.
- Triage: confirm with the owning team; if unauthorised, contact the CA to revoke, investigate how domain validation was passed (DNS, registrar account, web server) and rotate any exposed keys.
- Tune: suppress expected renewals by matching known ACME accounts, because short lifetimes mean many more certificates; see the Certificate Expiry Outages and 47-Day TLS Certificates Guide.
Metrics: percentage of registered domains under CT monitoring; mean time from log entry to triage; number of unauthorised certificates found and revoked; certificates from unapproved CAs per quarter; lookalike-domain certificates detected and taken down; previously unknown hosts added to the asset inventory from CT.
Framework mapping
| Framework | Reference | How CT monitoring applies |
|---|---|---|
| NIST CSF 2.0 | DE.CM-09 | Monitoring certificates and services for adverse events |
| NIST CSF 2.0 | ID.AM-08 | Certificates managed throughout their life cycle |
| NIST SP 800-53 Rev. 5 | SC-17, SI-4 | PKI certificate control and system monitoring |
| ISO/IEC 27001:2022 | A.5.7 | Threat intelligence from public certificate data |
| MITRE ATT&CK | T1583.001, T1588.004, T1608.003, T1596.003 | Domain and certificate preparation, and reconnaissance through CT |
Common misconceptions
- "CT stops rogue certificates": it does not. A mis-issued certificate with valid SCTs works until someone notices and it is revoked or distrusted.
- "Browsers watch the logs for me": browsers check that SCTs exist, not that the certificate was authorised. Only the domain owner knows what it requested.
- "Internal names in a public certificate stay private": the precertificate, with every subjectAltName, is public as soon as it is logged. Use a private CA for internal services, or a wildcard where policy allows, rather than listing internal hostnames.
- "A certificate in CT is legitimate": logging proves only that it was issued by a trusted CA. Phishing domains get logged certificates too.
- "CT covers our internal PKI": private CAs are outside browser CT policy. Monitor them through the CA database and your certificate inventory; see the AD CS Security Guide.
- "RFC 9162 is what everyone runs": v2 is published but production logs and browser policies are built on RFC 6962 and the Static CT API.
Common failure patterns
- Nobody subscribed: CT data exists for every domain, but no alert is configured, so an unauthorised certificate goes unnoticed for months.
- Alert fatigue from renewals: automated renewals flood the channel and analysts stop reading, missing the one certificate from an unexpected CA.
- Only the main domain watched: secondary, regional and acquired domains are left out, which is where forgotten services sit.
- No revocation path: the team finds a rogue certificate but has no CA contact or process, and the domain validation weakness that allowed it is never fixed.
- Internal topology leaked: hostnames such as
vpn-adminorjenkins-prodare published in public certificates and later found by attackers.
Related concepts
- CAA records: DNS records that restrict which CAs may issue for a domain; prevention that complements CT detection.
- Revocation and short lifetimes: how a bad certificate is withdrawn once found; see the PKI Basics Guide.
- TLS and service identity: SCTs are checked inside the handshake alongside chain and hostname validation; see the How TLS Works Guide.
- Machine identity: each public certificate is a machine credential with an owner and key; see the Machine Identity, PKI and Certificate Lifecycle Guide.
- Transparency logs beyond certificates: the same Merkle tree design is used for software signing transparency logs in the supply chain.
Practitioner checklist
- Search CT for every registered domain and record each certificate's CA, requester and owner.
- Subscribe all domains, including acquired and regional ones, to a CT monitoring service that alerts the SOC.
- Publish CAA records naming only your approved CAs.
- Alert on unapproved CAs, unexpected names, forbidden wildcards and lookalike brand domains.
- Document a revocation and investigation runbook with CA contacts.
- Keep internal hostnames out of public certificates; use a private CA for internal services.
- Feed newly discovered hosts from CT into the asset inventory and attack surface programme.
- Report CT metrics quarterly alongside certificate lifecycle metrics.
Standards and references
- IETF: RFC 6962, Certificate Transparency
- IETF: RFC 9162, Certificate Transparency Version 2.0
- Google Chrome: Certificate Transparency Policy
- Google Chrome: CT Log Policy
- Apple: Apple's Certificate Transparency policy
- C2SP: Static CT API
- Certificate Transparency: How CT works
- Certificate Transparency: Monitors
Related NHI Mgmt Group resources: PKI Basics Guide · How TLS Works Guide · Typosquatting and Lookalike Domains Guide · Machine Identity, PKI and Certificate Lifecycle Guide