Certificate Transparency: How to Monitor Your Domain's Certificates

Certificate Transparency (CT) is a system that logs every publicly-issued SSL certificate into public, append-only logs. This means anyone can see which certificates have been issued for any domain — and catch unauthorized or fraudulent certificates.

CT was created by Google in 2013 after incidents where CAs issued certificates for domains they shouldn’t have (notably the DigiNotar breach in 2011, which led to fraudulent Google certificates). Since 2018, all publicly-trusted CAs are required to submit every certificate to CT logs.

Why CT matters

Without CT (before 2018)

A CA could issue a certificate for google.com to someone who doesn’t own it. No one would know until the certificate was actively used in an attack. CAs operated on trust alone.

With CT

Every certificate is logged publicly. If a CA issues a certificate for google.com, it appears in CT logs within hours. Google (or anyone monitoring) can detect it immediately.

How to check CT logs for your domain

crt.sh — the most popular CT search tool

Go to crt.sh and enter your domain. You’ll see every certificate ever issued for that domain:

• Issuer — which CA issued it
• Not Before / Not After — validity period
• SAN — domain names the certificate covers

Example results for example.com:
  2026-05-08  Let's Encrypt R10       example.com, www.example.com
  2026-02-15  Let's Encrypt R10       example.com
  2025-11-20  Let's Encrypt R3        example.com, www.example.com
  ...

Command-line search

curl -s "https://crt.sh/?q=yourdomain.com&output=json" | jq '.[] | {issuer_name, not_before, not_after, common_name}'

What to look for

• Certificates you didn’t request — may indicate someone is impersonating your domain
• Unexpected CAs — if you only use Let’s Encrypt but see a DigiCert certificate, investigate
• Wildcard certificates you didn’t create — *.yourdomain.com from an unknown source
• Subdomains you don’t recognize — secret.yourdomain.com in a certificate you didn’t request

How CT works technically

1. CA issues a certificate and submits it to one or more CT logs
2. CT log returns a SCT (Signed Certificate Timestamp) — proof the certificate was logged
3. The SCT is embedded in the certificate (or served during TLS handshake)
4. Browsers verify the SCT — Chrome requires certificates to have valid SCTs from at least 2-3 CT logs
5. Anyone can monitor the logs for certificates issued for their domains

CT logs are append-only — certificates can be added but never removed or modified. This creates an auditable history.

Setting up CT monitoring

For automated monitoring, use a service that alerts you when new certificates are issued for your domain:

CT and GetHTTPS

When you get a certificate from GetHTTPS, Let’s Encrypt automatically submits it to multiple CT logs. You can verify by searching for your domain on crt.sh after issuance — your certificate will appear within minutes.

This is by design — public logging of all certificates is a security feature, not a privacy concern. The certificate itself (domain name, public key, CA) is already sent to every visitor during the TLS handshake.

Frequently asked questions

Can I opt out of Certificate Transparency?

No, for publicly-trusted certificates. Since 2018, all CAs must submit certificates to CT logs. Browsers (Chrome, Safari) reject certificates without valid SCTs. Private/internal CAs are exempt — they don’t submit to public CT logs.

Does CT reveal my server’s IP address?

No. CT logs contain the certificate (domain name, public key, CA, validity) but not the server’s IP address. DNS records reveal the IP — CT logs don’t add new information.

I found a certificate for my domain I didn’t request. What do I do?

1. Check the issuer — could it be your hosting provider’s AutoSSL?
2. Check the SAN — does it include domains you recognize?
3. If truly unauthorized, contact the issuing CA to request revocation
4. Check your DNS for unauthorized changes — someone may have pointed your domain to their server

How many CT logs exist?

Dozens. Major operators include Google (Argon, Xenon), Cloudflare (Nimbus), DigiCert, Sectigo, and Let’s Encrypt. Browsers require SCTs from multiple independent logs to prevent a single compromised log from hiding a fraudulent certificate.