What Is Certificate Transparency and Why It Matters

Certificate Transparency (CT) is a security framework designed to detect and prevent the misuse of SSL/TLS certificates. It creates an open, publicly auditable log of every SSL certificate issued by participating Certificate Authorities (CAs).

Before CT, a Certificate Authority could issue a certificate for any domain, and there was no easy way for the domain owner to know about it. A compromised or rogue CA could issue fake certificates for google.com or your-bank.com, enabling undetectable man-in-the-middle attacks.

CT solves this by requiring CAs to submit every certificate they issue to public logs. These logs are monitored by browsers, domain owners, and security researchers. If a certificate is issued without being logged, modern browsers will reject it.

The CT system has three components:

CT Logs: Append-only, publicly accessible logs operated by organizations like Google, Cloudflare, and DigiCert. When a CA issues a certificate, it submits it to one or more CT logs, which return a Signed Certificate Timestamp (SCT) — proof that the certificate has been logged.

Monitors: Services that watch CT logs for suspicious certificates. Domain owners can set up monitors to alert them whenever a new certificate is issued for their domain. This helps detect unauthorized certificate issuance quickly.

Auditors: Verify that CT logs are behaving correctly — that certificates aren't being removed, that the log is consistent, and that SCTs are valid.

Since 2018, Google Chrome requires all new certificates to have valid SCTs from at least two independent CT logs. Certificates without SCTs are rejected by Chrome, making CT effectively mandatory for all publicly trusted certificates.

Detect unauthorized certificates: If someone obtains a certificate for your domain (through CA compromise, social engineering, or domain validation flaws), CT logs will contain the evidence. Monitoring tools can alert you within minutes.

Detect phishing attempts: Phishers sometimes obtain legitimate certificates for domains that are typosquats of your brand (e.g., "go0gle.com"). CT monitoring can catch these before they're used in attacks.

Audit your CA: You can verify that your Certificate Authority is only issuing certificates you've requested. Any unexpected certificates for your domain should be investigated immediately.

Incident response: If a certificate is found to be issued improperly, CT provides the evidence needed to revoke it and investigate how it happened.

You can verify SSL certificates for any domain using LookMyIP's SSL Checker at lookmyip.com/ssl, which shows certificate details including the issuer, validity, and chain of trust.

Several free tools let you monitor CT logs for certificates issued for your domain:

• crt.sh: A free CT log search engine. Search for your domain to see every certificate ever issued for it.
• Facebook CT Monitor: Sends email alerts when new certificates are issued for domains you specify.
• Certspotter: Monitors CT logs and sends notifications for new certificates.
• Google Transparency Report: Includes a CT search tool.

What to look for:

• Certificates you didn't request
• Certificates from CAs you don't use
• Certificates for subdomains you don't recognize
• Certificates for lookalike domains (typosquatting)

If you find an unauthorized certificate, contact the issuing CA to have it revoked immediately, and investigate how the attacker obtained it (compromised domain validation, DNS hijacking, or CA compromise).

Certificate Transparency's guarantee is not that logs are honest. It is that dishonesty is detectable. The mechanism is a Merkle hash tree, and the design is worth understanding because it explains what CT can and cannot promise.

Every certificate submitted to a log becomes a leaf. Pairs of leaves are hashed together, then pairs of those hashes, and so on up to a single root hash that summarises the entire log. Change any certificate anywhere in the tree and the root hash changes.

The structure supports two proofs that are cheap to compute and cheap to verify.

Inclusion proof. To prove a specific certificate is in a log of ten million entries, the log supplies about 24 sibling hashes — enough to recompute the path from that leaf to the root. If the recomputed root matches the published one, the certificate is in the log. Verification cost grows logarithmically, so proving membership in a billion-entry log takes only 30 hashes.

Consistency proof. To prove that a newer version of the log is an append-only extension of an older one, the log supplies a small set of hashes showing the old root is embedded in the new tree. This is the crucial property: it makes retroactive removal detectable. A log operator who deletes an embarrassing certificate produces a tree that is not consistent with what it previously published, and any monitor holding the old root hash notices immediately.

When a certificate is submitted, the log returns a Signed Certificate Timestamp — a promise to include it within the Maximum Merge Delay, usually 24 hours. Browsers check for SCTs, not for actual inclusion, because checking inclusion at connection time would leak browsing history to the log operator. Auditors verify inclusion after the fact.

The honest summary: CT does not prevent misissuance. It guarantees that misissuance leaves a permanent, publicly verifiable record, which turns an invisible attack into one that is discovered — historically within hours.

CT is only useful if somebody watches. For a domain owner, monitoring costs almost nothing and is the fastest possible detection of a certificate issued without your knowledge.

Free monitoring services. Cloudflare, Facebook and several CAs offer email alerts when a certificate appears for a domain you have verified. crt.sh provides search and an RSS feed per domain. Setting one up takes five minutes and is the right baseline for most people.

Search directly. crt.sh accepts SQL-ish queries and wildcards:

https://crt.sh/?q=%25.example.com

That returns every certificate ever logged for any subdomain of example.com, with issuance dates and issuing CA.

Query the API for automation:

curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
  | jq -r '.[] | "\(.not_before)  \(.issuer_name)  \(.name_value)"' \
  | sort -u | head -50

Run that on a schedule, diff against the previous result, and alert on anything new.

What to do when an unexpected certificate appears. First establish whether it is genuinely unauthorised — the most common cause by far is a colleague or a service provisioning a certificate legitimately. Check with whoever manages your infrastructure before escalating. If it is genuinely unauthorised, contact the issuing CA's problem-reporting address immediately and request revocation; CAs are required by the Baseline Requirements to investigate within 24 hours. Then investigate how domain control validation was passed, because that is the actual compromise — usually DNS account access, email access, or a subdomain takeover.

Pair monitoring with a CAA record. CAA tells CAs which issuers are permitted for your domain, so unauthorised issuance is prevented rather than merely detected:

example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:security@example.com"

CT logs are public and permanent, and that has a side effect many organisations discover uncomfortably.

Every hostname in every certificate you have ever been issued is searchable forever. That means staging.example.com, admin-internal.example.com, jenkins.example.com, vpn-test.example.com and customer-acme.example.com are all public knowledge the moment a certificate is issued — regardless of whether those names appear in DNS, and regardless of whether the hosts are meant to be private.

Attackers rely on this. Enumerating subdomains from CT logs is now the first step in most reconnaissance, and it is faster and more complete than brute-force DNS guessing because it returns names nobody would guess.

Three mitigations are available.

Use wildcard certificates for internal names. A certificate for *.internal.example.com discloses only the parent, not the individual hostnames beneath it. The trade-off is a wildcard private key with broader scope, which is a real risk if it is compromised.

Use a separate domain for internal infrastructure. Nothing links example-corp-internal.example to your main brand, so enumeration of one does not reveal the other.

Use an internal CA for internal services. Certificates from a private CA are never logged, because CT applies only to publicly trusted issuers. This is the correct answer for services that are never reachable from the internet, and it removes the disclosure entirely.

What does not work is assuming obscurity. Names discovered via CT should be treated as public, and the security of those hosts must come from authentication and network controls rather than from nobody knowing they exist.

A useful exercise: run the crt.sh query above against your own domain and read the list. Most organisations find at least one hostname they had forgotten about, and forgotten hosts are the ones that are unpatched.

Is CT mandatory?

Effectively, yes, for anything users will visit. Chrome has required SCTs on all certificates issued since April 2018, and Safari has similar requirements. A publicly trusted certificate without valid SCTs produces a hard connection error in those browsers. Certificates from a private internal CA are exempt.

Can a certificate be removed from a log?

No. Logs are append-only, and consistency proofs make any removal detectable. This is deliberate: an attacker who could delete evidence of misissuance would defeat the entire system. A revoked certificate stays in the log with its revocation recorded separately.

Does CT prevent a compromised CA from issuing bad certificates?

No, and it does not claim to. It ensures the issuance becomes publicly visible, which is what converts an undetectable attack into a detectable one. In practice this has been highly effective — several CAs have been distrusted by browsers after CT revealed patterns of misissuance.

How quickly do certificates appear in logs?

Usually within seconds to minutes of issuance, since CAs submit before delivering the certificate in order to embed the SCTs. The Maximum Merge Delay allows up to 24 hours, but real logs are far faster.

Should I monitor domains I do not use?

Yes, if you own them defensively. An unauthorised certificate for a parked domain is a strong signal that someone has gained control of its DNS, which is exactly the situation nobody notices because nothing is running on it.