Certificate Transparency (CT) is one of those things you use every day without thinking about it. Every time your browser connects to an HTTPS site, Certificate Transparency is working in the background to help ensure the certificate you’re seeing is legitimate. Understanding it has practical implications if you manage SSL certificates.
The Problem CT Solves
Before Certificate Transparency, a certificate authority could issue a certificate for your domain without you knowing about it. This happened — not often, but it happened. DigiNotar was a CA that issued fraudulent certificates for major domains including Google. These certificates were used in real attacks before anyone noticed.
The question was: how do you detect when a CA issues a certificate for your domain without your authorization?
Certificate Transparency answers this by requiring that every certificate be logged in public, append-only logs before browsers will trust it. You can monitor these logs and get notified when a certificate is issued for your domains.
How It Works
When a CA issues a certificate today, it submits it to one or more CT logs (public, append-only Merkle tree databases). The log returns a Signed Certificate Timestamp (SCT) — a cryptographic receipt proving the cert was submitted.
The CA embeds the SCTs into the certificate, or delivers them via TLS extension or OCSP stapling. When your browser connects to a site, it checks for valid SCTs. Chrome requires at least 2 SCTs from trusted logs. Without them, Chrome shows a certificate error.
The logs are public and searchable. Anyone can query them. This is both the power and the privacy implication of CT.
The Privacy Angle
I find this comes up in conversations: CT logs expose all your subdomains publicly. If you issue a certificate for internal-api.example.com or staging.example.com, those subdomains appear in CT logs and are searchable by anyone.
This doesn’t mean they’re accessible — just that their existence is known. For truly internal services, you should use a private CA (not a public CA and public CT logs). But for anything with a publicly issued certificate, assume the subdomain name is public information regardless of whether you advertise it.
Reconnaissance tools routinely scan CT logs to discover subdomains. Security researchers use it legitimately; attackers use it to map infrastructure.
Searching CT Logs
crt.sh is the most accessible CT log search interface:
https://crt.sh/?q=example.comTry it with your domain. You’ll see every certificate ever issued for that domain (and often wildcards and subdomains). I use this regularly to check if any unexpected certificates exist for domains I manage.
API usage:
curl "https://crt.sh/?q=example.com&output=json" | python3 -m json.toolOther search tools: Censys (censys.io/certificates), Google’s Transparency Report.
Monitoring Your Domains
Facebook has a free CT monitoring service at developers.facebook.com/tools/ct/. Enter a domain, provide a webhook or email, and you’ll be notified when a new certificate is issued for that domain.
I’ve set this up for all production domains I manage. The alerts come through within minutes of certificate issuance. It won’t stop an attack, but it means I know about it quickly — and most of the time it’s just my own certificate renewals, which is a good confirmation they’re working.
Other monitoring options:
certspotter— open source CT log monitor you can self-hostct-monitor— community tools for monitoring CT logs- crtmgr.com’s certificate monitoring features alert on both expiry and new issuance
Checking SCTs in a Certificate
Inspect SCTs in a certificate:
openssl x509 -noout -text -in certificate.pem | grep -A3 "CT Precertificate SCTs"Or for a live site:
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -text | grep -A 20 "CT Precertificate"You’ll see timestamps from specific CT log operators: Google’s Argon, Cloudflare’s Nimbus, DigiCert’s Yeti, etc.
What Happens Without CT
If a certificate doesn’t have valid SCTs, Chrome (and other Chromium-based browsers) shows a NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED error. This started being enforced in 2018.
In practice, certificates from any major CA will have SCTs — the CAs handle CT submission as part of the issuance process. Where you might see issues:
- Very old certificates issued before CT was required
- Certificates from CAs with CT compliance issues
- Self-signed certificates or private CA certificates (which don’t go through public CT logs at all)
- Test certificates from Let’s Encrypt staging environment
If you use Let’s Encrypt (even the staging server for testing), all certs are CT logged. Private CAs are different — they don’t submit to public CT logs, which is why they require separate root trust installation.
CT and Misissuance Detection
The real value of CT became clear in 2017 when a researcher discovered that Symantec had issued test certificates that were included in CT logs. This led to a broader investigation that found thousands of improperly issued certificates. Browsers eventually distrusted Symantec’s CA roots.
Without CT, this scale of misissuance might never have been discovered. The logs provide an audit trail that makes certificate abuse detectable.
For domain owners, CT means:
- Any certificate for your domain will be publicly visible
- You can monitor for unauthorized issuance
- Rogue certificates can be detected (though not prevented)
DNS CAA Records as Complementary Protection
CT detects unauthorized certificates after they’re issued. CAA records in DNS prevent them from being issued in the first place.
A CAA record specifies which CAs are authorized to issue certificates for your domain:
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issue "digicert.com"
example.com. IN CAA 0 issuewild "letsencrypt.org"CAs are required to check CAA records before issuance. If your CAA records don’t include a CA, that CA should refuse to issue. Combined with CT monitoring, you have both prevention (CAA) and detection (CT).
The DNS CAA records guide goes deeper into CAA configuration and how to set it up properly.
The Ecosystem Health
CT has become a fundamental part of the web PKI. As of 2024, there are multiple CT log operators running logs: Google, Cloudflare, DigiCert, Sectigo, and others. The append-only nature and cryptographic proofs make tampering detectable.
It’s not perfect — the system relies on log operators behaving honestly, and there are ongoing discussions about centralization risks. But compared to the pre-CT world where certificate misissuance was effectively undetectable in practice, it’s a significant improvement.
For anyone managing SSL certificates professionally, understanding CT is worth the time. The ability to monitor your domains through CT logs is a practical security control that takes maybe 30 minutes to set up and runs in the background from then on.