Why was Certificate Transparency created?

CT was created after high-profile incidents where Certificate Authorities issued fraudulent certificates for domains like google.com without the domain owner's knowledge. Without CT, these rogue certificates could enable undetected man-in-the-middle attacks for months or years.

When a CA issues a certificate, it submits it to one or more CT logs. The log server returns a cryptographically signed Signed Certificate Timestamp (SCT), which the CA embeds in the certificate. Browsers verify the SCT is present and valid before accepting the certificate as trusted.

What is a Signed Certificate Timestamp (SCT)?

An SCT is a cryptographic promise from a CT log server that it has received a certificate and will include it in its public ledger within a set time window called the Maximum Merge Delay (MMD). Browsers use the SCT to verify a certificate was properly logged before trusting it.

Does Certificate Transparency prevent certificate misissuance?

CT does not prevent misissuance directly — a rogue CA can still issue a bad certificate. However, CT guarantees the misissuance will be publicly visible within hours, allowing domain owners and browser vendors to detect and revoke it before widespread damage occurs.

How can I check if my certificate is in a CT log?

You can use free tools like crt.sh or Google's Certificate Transparency search to look up any domain and see every certificate logged for it. This is a useful monitoring step to catch unauthorized certificates issued for your domain by any CA in the world.

Certificate Transparency: How CT Logs Stop Bad TLS Certs

Q: What is Certificate Transparency?

Certificate Transparency (CT) is an open framework that requires Certificate Authorities (CAs) to publicly log every TLS certificate they issue. This creates an append-only, auditable record so that domain owners, browsers, and researchers can detect misissued certificates almost immediately.

Introduction

In 2011, a Dutch Certificate Authority called DigiNotar was silently compromised. Attackers used it to issue hundreds of fraudulent TLS certificates for major domains including google.com. Iranian internet users were subjected to man-in-the-middle attacks for weeks before anyone detected the breach — because there was no public record of which certificates had been issued. By the time the fraud was discovered, DigiNotar had to be shut down entirely.

That incident exposed a fundamental weakness in the web’s trust model that Certificate Transparency (CT) was later built to close: there was no way to know if a Certificate Authority (CA) had issued a certificate for your domain without your knowledge. A rogue certificate could silently redirect your users’ encrypted traffic to an attacker.

Today, every major browser requires that every trusted TLS certificate be publicly logged before it is accepted. In this article, you will learn exactly how CT logs work, what they protect against, and how to use them to monitor your own domains.

What Is Certificate Transparency?

Certificate Transparency is an open framework and set of standards defined in IETF RFC 9162. It requires every Certificate Authority — the companies that issue TLS certificates — to submit every certificate they issue to one or more public, append-only logs before browsers will accept it.

The result is a publicly auditable ledger of every TLS certificate in existence. If a CA issues a certificate for yourbank.com without your permission, it appears in the CT log within hours. You can query it with free tools and detect the misissuance before an attacker uses it to target your users.

The framework has three main components: CT logs (the append-only databases), Certificate Authorities (who submit certs to the logs), and monitors and auditors (automated systems that watch the logs for suspicious certificates). DNSSEC provides a similar verification layer for DNS responses. Your browser ties it all together by refusing certificates that lack proof of CT logging.

How Certificate Transparency Works

The CT system operates through a tightly choreographed flow between CAs, log servers, and browsers:

Certificate Issuance: A website owner requests a certificate from a CA. The CA validates the domain ownership and prepares the signed certificate.
Log Submission: Before delivering the certificate, the CA submits it to at least two approved CT log servers. Each log returns a Signed Certificate Timestamp (SCT) — a cryptographic receipt proving the log has received the certificate.
SCT Embedding: The CA embeds the SCTs into the final certificate before handing it to the website. The SCTs can also be delivered via TLS extensions or OCSP stapling.
Browser Verification: When your browser connects to a site, it checks that the certificate contains valid SCTs from approved logs. If SCTs are missing or invalid, the browser rejects the connection with a hard error.
Log Monitoring: Independent monitors continuously download and scan CT logs for suspicious entries. Domain owners can subscribe to alerts for any new certificate logged against their domains.

This video explains how CT logs work as an auditable record of TLS certificates and why browsers require SCTs.

The CT lifecycle: from CA issuance through log submission and SCT embedding to browser verification.

Certificate Transparency vs Traditional PKI

Before CT, the web relied entirely on a trust list of pre-approved CAs bundled into every browser. If any CA on that list misbehaved — whether through compromise, coercion, or negligence — it could issue fraudulent certificates for any domain. There was no detection mechanism.

CT does not replace the traditional Public Key Infrastructure (PKI) model. CAs still issue certificates and browsers still maintain a trust list. What CT adds is a mandatory transparency layer: every issuance must be publicly witnessed and recorded. Misbehavior is no longer a question of whether it will be discovered, but when.

The critical difference is accountability. A CA that issues a bad certificate today leaves a permanent, cryptographically signed record in a public log. Browser vendors like Google and Apple can use that record to distrust the CA, as Google did with Symantec’s CA business in 2018 after discovering systematic misissuance in CT logs.

Feature	Traditional PKI (without CT)	PKI with Certificate Transparency
Misissuance detection	Passive — only if noticed by accident	Active — logged within hours, publicly visible
Public audit trail	None	Permanent, append-only log
Domain owner monitoring	Not possible	Subscribe to alerts for your domain
CA accountability	Relies on trust policies alone	Cryptographic evidence of every issuance

Real-World Use Cases

Security teams use CT logs for domain monitoring as a core part of their threat intelligence. By subscribing to a CT monitoring service like Facebook’s Certificate Transparency Monitor or crt.sh alerts, you receive an immediate notification whenever a certificate is issued for your domain. This gives you a real-time view of both authorized certificates (from your own team) and unauthorized ones (potential phishing infrastructure being set up against you).

Browser vendors use CT log data for CA enforcement actions. When Google detected that Symantec’s CAs had improperly issued over 30,000 certificates, the evidence came entirely from CT log analysis. Google announced it would progressively distrust Symantec certificates, which forced a major restructuring of Symantec’s CA business. CT gave browsers the evidence needed to act decisively.

Penetration testers use CT logs for reconnaissance. Because CT logs contain every subdomain that has ever had a certificate issued, searching crt.sh for a target domain often reveals internal subdomains, staging environments, and legacy applications that are not publicly advertised but are still reachable on the internet.

Common Mistakes to Avoid

A common misconception is that CT prevents misissuance. It does not. A compromised CA can still issue a fraudulent certificate — CT simply ensures that fraudulent certificate becomes immediately public. The protection comes from monitoring those logs and revoking bad certificates quickly, not from the logs blocking issuance.

Many organizations set up CT monitoring alerts but fail to act on them. An alert that a new certificate was issued for api.yourcompany.com is only useful if someone reviews it and can distinguish a legitimate internal deployment from an unauthorized certificate. You need an operational process, not just a feed subscription.

Finally, organizations sometimes assume that because their browser enforces CT, they are automatically protected. CT enforcement by browsers only applies to new certificates. Certificates issued before CT requirements were enforced (pre-2018) may not have SCTs and can still be trusted by some browsers in legacy contexts.

Getting Started

The first step is to search crt.sh for your primary domain and every subdomain you own. Review all the certificates you find — you may discover certificates issued by CAs you have never authorized, or for subdomains you thought were decommissioned. Each unexpected entry warrants immediate investigation.

Next, set up automated CT monitoring. Services like Facebook’s CT monitoring tool or Cert Spotter will send you an email or webhook notification whenever any CA issues a certificate for your domain. Configure these alerts for your primary domain and all known subdomains.

Finally, if you operate a CA or manage certificates internally, ensure your issuance pipeline submits to at least two approved CT logs and properly embeds SCTs. Non-compliant certificates will be rejected by Chrome and Safari. For the TLS fundamentals that underpin CT, read our detailed guide on TLS 1.3 vs TLS 1.2. To understand how KMS protects the private keys behind these certificates, see Key Management Services. For apps that need an additional layer of trust enforcement beyond CT, read How Certificate Pinning Works to learn how to lock connections to specific certificates or public keys.