Certificate Transparency Explained: CT Logs and Mis-Issuance

The trust that HTTPS depends on has a quiet weak point: any of the many certificate authorities your browser trusts can issue a certificate for any domain. Most of the time that is fine, because a legitimate authority checks that you control the domain before it issues. But if an authority is careless, tricked, or compromised, it can issue a certificate for a domain that does not belong to the requester, and historically the real owner had no way to know.

Certificate Transparency, CT, was built to remove that blind spot. The idea is simple and powerful: make every publicly trusted certificate appear in a public log that anyone can watch. An authority can still make a mistake, but it can no longer make one in secret. Issuance becomes a matter of public record, and public record is something defenders can monitor.

The problem before CT

A certificate authority vouches for the link between a domain name and a public key. Your browser trusts a set of these authorities. The trouble is that the trust is broad: each trusted authority can issue for any name, and there was no shared, public account of what had been issued.

So imagine an attacker who compromises a certificate authority, or convinces it through a flawed validation process to issue login.yourbank.example to the wrong party. That certificate would be fully valid in every browser. The attacker could stand up a convincing phishing site with a green padlock. The real owner of the domain would have no notification, no log to check, nothing. The mis-issuance was invisible.

How CT works

CT introduces public, append-only logs. When a certificate authority issues a certificate, it submits it to one or more of these logs. The log records it permanently and returns a receipt.

Three properties make the logs trustworthy:

• Append-only. Entries can be added but never removed or changed. The logs use Merkle trees, so the entire contents hash up to a single root value. If anyone tampered with a past entry, the root would not match and the tampering would be exposed.
• Publicly readable. Anyone can download and inspect the entries. There is no privileged access.
• Verifiable. A log makes cryptographic promises about inclusion that clients and auditors can check independently, so a misbehaving log is detectable too.

The receipt the log returns is called a Signed Certificate Timestamp, an SCT. It is the log's signed promise that the certificate is included. Certificates, or the TLS handshake, carry these SCTs along.

What forces authorities to log

A public log only helps if certificates actually end up in it. The enforcement comes from the browsers. Modern browser policies require a publicly trusted certificate to present valid SCTs, usually from more than one independent log, or the browser refuses to trust it.

That requirement flips the incentive. An authority that does not log its certificates issues certificates that do not work. So logging is no longer optional goodwill; it is a condition of being trusted at all. The result is that essentially every publicly trusted certificate issued today is in the logs.

Element	What it is	Who relies on it
CT log	Public, append-only record of issued certificates	Auditors, monitors, browsers
SCT	Signed proof a certificate was submitted to a log	Browsers, at connection time
Merkle tree	Structure that makes the log tamper-evident	Anyone verifying log integrity
Monitor	A service that watches logs for chosen domains	Domain owners, defenders

Why this matters to defenders

The headline use of CT for the people who run the internet's trust infrastructure is holding certificate authorities accountable. CT has already exposed authorities issuing certificates that violated the rules, and some of those authorities lost their trusted status as a consequence. That accountability keeps the whole system honest.

But the day-to-day value for an ordinary organisation is different and more direct: monitoring your own names. Because every certificate for your domains lands in a public log, you can watch those logs and get alerted the instant a certificate is issued for one of your names.

Consider what a certificate you did not request tells you:

• A certificate for a subdomain you do not recognise may be shadow IT, a team standing up infrastructure outside the process, which is worth knowing about.
• A certificate for a name close to yours, on a different domain, may be an attacker preparing a phishing site to impersonate you.
• A certificate for one of your real names that your team did not order is a red flag for compromise, either of your DNS, your registrar, or a certificate authority.

In every case, CT gives you the signal early, often before the impersonating site is even live.

How to use CT in practice

1. Enumerate the domains and subdomains you own. You cannot monitor names you have not listed, and forgotten domains are exactly where mis-issuance hides.
2. Set up CT monitoring across all of them. Use a monitor that watches the logs and alerts you when a certificate appears for any name you care about, including wildcards and close look-alikes.
3. Tune alerts to catch look-alike domains. Impersonation often uses a similar name on a domain you do not own. Watching only your exact names misses this, so include typo and homoglyph variants.
4. Have a response for an unexpected certificate. Decide in advance who investigates, how you confirm whether it is your own team or an attacker, and how you get a bad certificate revoked.
5. Use CT as recon for your own attack surface. The logs are a complete list of certificates issued for your names. That is a free inventory of internet-facing services, including ones nobody remembered to document.

Certificate Transparency does not make the certificate system perfect. Certificate authorities can still err. What CT does is refuse to let those errors stay hidden. For the operators of internet trust, that means accountability. For you, the person who owns a domain, it means a public feed of every certificate anyone issues in your name, and a chance to react before a mistake or an attack becomes a breach. Point a monitor at your domains and read the feed.

For tracking the phishing infrastructure and impersonation campaigns that CT monitoring often surfaces first, our exploit intelligence dashboard follows how look-alike domains and fraudulent certificates feed into active attacks.

The Merkle tree that makes a log tamper-evident

The append-only promise of a CT log rests on a specific data structure, and understanding it explains why a log operator cannot quietly rewrite history. A CT log is a Merkle tree, also called a hash tree. Each certificate entry sits at a leaf, and each leaf is hashed. Pairs of leaf hashes are concatenated and hashed together to form the next level up. Those results are paired and hashed again, and the process repeats until a single value remains at the top. That top value is the Merkle tree root, often called the tree head.

The property that matters is that the root depends on every leaf beneath it. Change one certificate entry anywhere in the tree, and its leaf hash changes, which changes the parent hash, which changes that parent's parent, all the way up to a different root. There is no way to alter a past entry without producing a different tree head, and the tree head is signed and published. Auditors record the tree head over time, so a log that tried to swap out or remove an old entry would be caught the moment its new root failed to reconcile with a root that observers already saved.

Two kinds of cryptographic proof make this checkable without downloading the whole log. An inclusion proof, also called an audit proof, is a short list of sibling hashes that lets a verifier recompute the path from a specific leaf up to the root. If the recomputation matches the signed tree head, the certificate is proven to be in the log. A consistency proof lets a verifier confirm that a newer, larger tree is a strict superset of an older tree, meaning entries were only appended and nothing earlier was changed or dropped. Together these let anyone verify the log's honesty with a handful of hashes rather than a full copy.

How SCTs travel to the browser

A Signed Certificate Timestamp is the log's signed receipt, and there are three defined ways for it to reach the browser during a connection. Knowing them explains why the system works even for certificate authorities and servers with different capabilities.

The first and most common path is embedding the SCT directly in the certificate. Here the certificate authority submits a precertificate to the logs, collects the SCTs, and bakes them into the final certificate as an extension before signing it. The server operator does nothing special, because the SCTs ship inside the certificate the server already serves. This is why most operators get CT compliance for free simply by obtaining a normal certificate.

The second path is a TLS extension. The server presents SCTs during the handshake through a dedicated extension, separate from the certificate itself. This suits operators who want to add or rotate SCTs without reissuing the certificate.

The third path is OCSP stapling, where the SCTs ride along with the stapled revocation response the server presents. This is the least common of the three.

Whichever path is used, the browser's requirement is the same. A publicly trusted certificate must present a sufficient set of valid SCTs, generally from more than one independent log, or the browser treats the certificate as untrusted and blocks the connection. That policy is the enforcement engine that makes logging mandatory in practice.

A worked example: monitoring a domain you own

Consider how CT monitoring plays out for an organisation that owns example-corp.example and a handful of subdomains. The security team registers the apex domain and a wildcard pattern with a CT monitor. From that point, every time any certificate authority anywhere logs a certificate whose names match, the monitor raises an alert.

One morning the monitor reports a newly logged certificate for vpn-test.example-corp.example, issued by a certificate authority the company does use. The team checks their inventory and finds no record of this name. Two explanations are plausible. It may be shadow IT, an engineer who stood up a test VPN gateway and requested a certificate through a self-service process outside the change record. Or it may be an early sign of compromise, someone who gained enough access to request a certificate under the company's own domain. Either way, the certificate that was invisible before CT is now a concrete lead the team can chase the same day it was issued.

A second alert is more alarming. The monitor flags a certificate for login.example-corp.example.secure-account.example, a name that places the company's brand as a subdomain of a completely different registered domain the company does not own. That is a classic phishing setup, a look-alike hostname designed to read as legitimate at a glance. The certificate was logged before the phishing site went live, so the team has a window to warn staff, prepare takedown requests, and watch for the campaign, all before a single victim reaches the page.

Neither of these signals existed in a world without CT. The value is not that CT prevented the certificate, because it did not. The value is that CT surfaced the certificate as a public, timestamped record the defender could act on immediately.

CT compared with related trust controls

Certificate Transparency is one of several mechanisms that harden the web PKI, and they are often confused. Each addresses a different failure and they compose rather than compete.

Control	What it addresses	Nature
Certificate Transparency	Detecting mis-issued or unexpected certificates	Detective, public logs monitored after the fact
CAA records	Restricting which certificate authorities may issue for a domain	Preventive, a DNS record authorities must honour
OCSP and CRLs	Revoking certificates that should no longer be trusted	Corrective, checked at or before connection time
HSTS	Forcing browsers to use HTTPS and refuse downgrade	Preventive, a policy the browser enforces
Certificate pinning	Binding a site to specific keys or issuers	Preventive, now largely superseded by CT for the web

The contrast worth drawing is between CAA and CT. A CAA record is a preventive control that tells authorities which of them are allowed to issue for your domain, and a well-behaved authority checks it before issuing. CT is a detective control that records what was actually issued, including issuance that ignored or predated your CAA record. CAA reduces the chance of mis-issuance, and CT catches the cases that slip through. Running both is standard practice for a domain owner who takes issuance seriously.

Common misconceptions about CT

A few beliefs about Certificate Transparency lead people astray, and correcting them sharpens how you use the system.

CT prevents mis-issuance. It does not. Nothing in CT blocks a certificate authority from issuing a certificate it should not. CT makes that issuance public and permanent so it can be detected and answered. The prevention comes from other controls such as CAA and the authority's own validation, while CT supplies visibility.

Only large organisations need CT monitoring. Any domain owner benefits, and small organisations often benefit most, because they are the least likely to notice a phishing certificate through other means. Monitoring is cheap and covers domains an owner may have forgotten they hold, which is exactly where mis-issuance tends to hide.

Private internal certificates appear in CT. Public CT logs cover publicly trusted certificates, the ones chained to a certificate authority in browser trust stores. Certificates from a private internal certificate authority that browsers do not trust publicly are not required to be logged and generally are not. CT is a property of the public web PKI.

An SCT proves the certificate is trustworthy. An SCT proves only that the certificate was submitted to a log. It says nothing about whether the certificate was issued to the right party. The trust decision still depends on the certificate authority's validation and on monitors catching anything wrong. The SCT is a logging receipt, not a stamp of legitimacy.

CT logs let you read certificate private keys. Logs contain certificates, which hold public keys and metadata, never private keys. A private key never leaves the party that generated it, so nothing sensitive is exposed by a certificate appearing in a public log.

How CT evolved

Certificate Transparency grew out of a concrete crisis of confidence in the certificate authority system. In the early 2010s, several high-profile incidents showed that a single careless or compromised authority could issue certificates for major domains, and that the affected domain owners had no reliable way to learn about it. The web PKI depended on every one of hundreds of trusted authorities behaving perfectly, with no shared record when one did not.

Engineers at Google proposed CT as a response, and the first version was published as RFC 6962 in 2013. The design goal was modest and powerful at once: make issuance observable. Rather than trying to make certificate authorities incapable of error, CT made their output a matter of public record so errors could be found and answered.

Adoption came through browser policy. Once a major browser began requiring SCTs for certain certificates and then broadened that requirement, certificate authorities had no choice but to log, because unlogged certificates stopped working for users. Over several years the requirement expanded until, in practice, essentially every publicly trusted certificate is logged. The protocol was later revised as RFC 9162, Certificate Transparency version 2.0, refining the data structures and proofs while keeping the core idea intact.

The payoff has been visible. CT has surfaced real cases of authorities issuing certificates that violated the rules, and several authorities lost their trusted status as a direct consequence of what the logs revealed. The system turned certificate issuance from a private act into a public one, and that shift has held the whole trust ecosystem to account.

Frequently asked questions

Does Certificate Transparency stop a bad certificate from being issued? No. CT is a detection mechanism, not a prevention one. It cannot stop a certificate authority from issuing a certificate, and it makes every issued certificate appear in a public, append-only log where it can be found. Prevention comes from other controls such as CAA records and the authority's validation process, while CT provides the visibility to catch what those miss.

What is an SCT and why does it matter? A Signed Certificate Timestamp is a log's signed promise that it has recorded a certificate. It matters because modern browsers require publicly trusted certificates to present valid SCTs, usually from multiple independent logs, or they refuse to trust the certificate. That browser requirement is what compels certificate authorities to log in the first place.

Are my internal or private certificates listed in CT logs? Generally not. CT covers publicly trusted certificates that chain to authorities in browser trust stores. Certificates issued by a private internal certificate authority, which browsers do not trust publicly, are not required to be logged and usually are not. If you run an internal PKI, those certificates stay out of the public logs.

How quickly does a new certificate show up in CT? Certificates typically appear in the logs at or very near the time of issuance, because logging is part of the issuance flow for embedded SCTs. Monitors that watch the logs can alert within minutes to hours, which is often before an impersonating site built on a fresh certificate is even live.

What should I do if I find a certificate I did not request? Treat it as a potential incident. Confirm whether an internal team requested it as shadow IT, and if not, investigate for compromise of your DNS, registrar, or an authority. For a genuinely mis-issued or malicious certificate, contact the issuing certificate authority to request revocation and preserve the log entry as evidence.

Can I use CT logs for anything besides catching attacks? Yes. Because the logs contain every certificate issued for your names, they are a free inventory of your internet-facing services, including ones nobody documented. Security teams use CT as reconnaissance on their own attack surface, and researchers use it to study issuance across the whole web PKI.

Do CT logs contain private keys or sensitive data? No. Logs hold certificates, which contain public keys, domain names, validity dates, and issuer information. Private keys never appear, because they never leave the party that generated them. The names in a certificate are the main privacy consideration, which is why some deployments use wildcard certificates to avoid publishing every subdomain.

Related guides

• What Is PKI
• How HTTPS Works
• How Digital Signatures Work
• BGP Hijacking Explained