Home / Blog / Certificate Transparency: How to Detect Unauthorized Certificate Issuance

Certificate Transparency: How to Detect Unauthorized Certificate Issuance

Certificate Monitoring By Taylor Reed 6 min read

Every publicly trusted TLS certificate issued for your domain, by any certificate authority, is logged to public Certificate Transparency (CT) logs before browsers will accept it. This is mandatory as of 2018. The logs are append-only, cryptographically verifiable, and completely public.

That means if someone requests a certificate for your domain (legitimately or otherwise), you can find out. The question is whether you're actually looking.

Certificate Transparency was designed to detect mis-issuance and rogue certificates. For domain owners, it's a monitoring surface: if a certificate appears for your domain and you didn't request it, you have a problem.

How Certificate Transparency Works

CT is a framework that requires CAs to submit certificates to publicly auditable logs before issuance. Browsers enforce this by rejecting certificates that lack valid CT log entries (called Signed Certificate Timestamps, or SCTs).

The flow:

  1. A certificate authority issues a certificate for example.com.
  2. Before delivering the certificate, the CA submits it to multiple CT logs operated by Google, Cloudflare, DigiCert, and others.
  3. Each log returns a signed timestamp proving the certificate was logged.
  4. The CA includes these SCTs in the certificate or delivers them via TLS extension.
  5. When a browser connects to example.com, it verifies that the certificate has valid SCTs from recognized logs.

If the certificate lacks sufficient SCTs, the browser rejects it with a certificate transparency error. This forces CAs to log every certificate, which makes all issuance publicly auditable.

Why CT Logs Matter for Domain Owners

CT logs are a complete, publicly searchable record of every certificate issued for your domain. You can query the logs to see:

  • When certificates were issued
  • Which CA issued them
  • What hostnames they cover (CN and SANs)
  • Certificate validity period

If you see a certificate you didn't request, it's either:

  1. Legitimate issuance you forgot about (a third-party CDN, hosting provider, or vendor that manages certificates on your behalf).
  2. Internal issuance from a forgotten system (a staging environment, legacy service, or shadow IT).
  3. Unauthorized issuance (someone requested a certificate for your domain from a CA and passed domain validation, or a compromised CA issued a cert without proper authorization).

Scenario 3 is rare but not unheard of. DigiNotar (2011), Comodo (2011), and Symantec (2015-2017) all had incidents where certificates were issued without proper validation. CT logs make these incidents detectable.

Monitoring CT Logs

You can search CT logs manually or set up automated monitoring.

Google's crt.sh (https://crt.sh) is the most popular CT log search tool. Enter your domain and you'll see all logged certificates:

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

Results show issuer, issuance date, expiration, and Subject Alternative Names (SANs). You can filter by wildcard certificates, specific CAs, or date ranges.

Another option is Censys (https://search.censys.io), which indexes CT logs along with internet-wide scans. It's useful for correlating certificates with live hosts.

Automated Monitoring

Manual searches don't scale. If you're managing more than a handful of domains, you want automated alerts when new certificates appear.

Options:

  1. Facebook's CT monitoring tool (https://developers.facebook.com/tools/ct/): Free service that emails you when new certificates are logged for domains you register.
  2. Certificate monitoring services: Certificate Monitoring from Generator Labs provides real-time alerts when certificates are issued, with validation against your known certificate inventory.
  3. Self-hosted monitoring: Query CT logs via their APIs and alert on new entries. Google's CT log API and the certstream real-time feed are common starting points.

Set a baseline: catalog all certificates you expect to see (your primary domain, subdomains, CDN provider, email gateway, etc.). Alert on anything outside that baseline.

What to Do When You Find an Unauthorized Certificate

If you find a certificate for your domain that you didn't authorize:

  1. Verify it's actually unauthorized. Check with your team, hosting provider, CDN, and any third-party services. Sometimes vendors issue certificates on your behalf (Cloudflare, AWS CloudFront, etc.).
  2. Check domain validation. How did the requester prove control of your domain? Common validation methods: DNS record (DNS-01), HTTP challenge (HTTP-01), email to admin@yourdomain (deprecated but still used). If DNS or HTTP validation succeeded, your infrastructure may be compromised.
  3. Report the mis-issuance. Contact the issuing CA immediately. Provide the certificate serial number and request revocation. CAs are required by baseline requirements to investigate mis-issuance reports.
  4. Revoke the certificate. If it's a legitimate mis-issuance, the CA will revoke it and add it to their CRL and OCSP responder.
  5. Add a CAA record. CAA (Certification Authority Authorization) is a DNS record that specifies which CAs are allowed to issue certificates for your domain.

Preventing Unauthorized Issuance with CAA

CAA records tell CAs "you may not issue a certificate for this domain unless you are on this list."

Example CAA record:

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

This says:

  • Only Let's Encrypt may issue certificates for example.com.
  • Only Let's Encrypt may issue wildcard certificates.
  • If a CA sees this record and receives a certificate request from an unauthorized party, they must send a report to security@example.com.

CAs are required to check CAA records before issuance. If the domain has a CAA record and the CA isn't listed, issuance must be refused.

Not all CAs enforce CAA perfectly, but it's a strong signal. If you use a single CA or a small set of CAs, publish a CAA record.

You can verify CAA records with the DNS lookup tool on mrdns.com, which supports CAA record queries.

CT Logs and Certificate Expiration Monitoring

CT logs tell you about new issuance. They don't tell you when existing certificates are about to expire. For that, you need active certificate monitoring: regular checks of your live endpoints to verify certificate validity, expiration dates, chain completeness, and revocation status.

Certificate Monitoring combines both: CT log monitoring for unauthorized issuance and active endpoint monitoring for expiration, misconfiguration, and revocation.

Baseline Your Certificates

Before you set up monitoring, establish a baseline:

  1. List all domains and subdomains you manage. Include wildcards if you use them.
  2. Search CT logs for each domain. Catalog all active certificates.
  3. Identify the issuer and validation method for each. Let's Encrypt, DigiCert, AWS ACM, etc.
  4. Document third-party services that issue certificates on your behalf. CDNs, hosting providers, email gateways.
  5. Set up alerts for new certificates. Anything outside your baseline should trigger review.

Once you have the baseline, monitoring becomes straightforward: new certificate appears, check against baseline, alert if unknown.

What Good CT Monitoring Looks Like

A well-monitored domain has a small, predictable set of certificates. New certificates appear only during planned renewals or when you spin up new infrastructure. Unexpected entries are investigated within hours, not weeks.

Most of the time, monitoring is silent. When it's not, you want to know immediately.

Certificate Transparency made TLS issuance auditable. Use that visibility. Monitor your logs, set up alerts, add CAA records, and catch unauthorized issuance before it becomes a security incident.

Back to Blog