Certificate Transparency Logs: How Attackers Find Your Subdomains

Introduction

A developer requests a public TLS certificate for grafana-staging.example.com so the team can test a dashboard over HTTPS.

The hostname is not linked from the website. It is not in the sitemap. It is not supposed to be easy to find.

After the certificate appears in public CT data or a CT search index, anyone watching those logs can see the hostname, add it to a subdomain list, resolve it, fingerprint the service, and decide whether it deserves review.

Certificate Transparency is not a vulnerability. It is a public accountability system for certificate issuance. The risk is that public certificate data can reveal more of your attack surface than your asset inventory does.

How Certificate Transparency works at the protocol level

Certificate Transparency is a public logging system for TLS certificates.

When a certificate authority issues a public certificate, the certificate or precertificate is submitted to one or more CT logs. Each log is append-only and backed by a Merkle tree, which allows monitors and auditors to verify that entries were included without trusting a single certificate authority blindly.

In many Web PKI flows, the CA submits a precertificate first, receives Signed Certificate Timestamps, then includes SCT evidence with the final certificate.

The SCT is the log's signed promise that the certificate or precertificate will be included in the log within the log's maximum merge delay. Browsers and client ecosystems can then require valid SCT evidence before treating a certificate as CT-compliant.

• Certificate authority — The CA validates control of the domain and issues the certificate or precertificate.

• CT log — The public append-only log receives certificate entries and maintains a cryptographically verifiable history.

• Signed Certificate Timestamp — The SCT is the log's signed promise that the certificate will be included in the log.

• Monitor — A monitor watches CT logs for certificates matching domains, brands, organizations, or suspicious issuance patterns.

• Auditor — An auditor checks whether the log behaves correctly and whether inclusion promises can be verified.

What Certificate Transparency logs expose

Certificate Transparency logs do not expose private keys.

They expose certificate metadata, including DNS names contained in certificates. The Subject Alternative Name extension can include every DNS name the certificate covers.

If those names reveal staging systems, internal naming conventions, admin tools, VPN gateways, temporary apps, or vendor integrations, CT logs become a subdomain discovery feed.

A public certificate like this turns hidden naming into public evidence.

• Vulnerable certificate naming pattern — ```text Certificate subject alternative names: DNS:www.example.com DNS:api.example.com DNS:grafana-staging.example.com DNS:admin-prod.example.com DNS:vpn-legacy.example.com DNS:kibana-dev.example.com ```

• Safer certificate naming pattern — ```text Certificate subject alternative names: DNS:www.example.com DNS:api.example.com DNS:app.example.com ```

• Wildcard certificate nuance — Wildcard certificates can reduce the number of individual hostnames logged, but they do not hide the base domain and they do not secure any service. They also need careful key management because a reused wildcard key can increase blast radius.

• Important limitation — Renaming certificates does not secure exposed services. It only reduces unnecessary disclosure. The real fix is authentication, network restriction, service ownership, DNS cleanup, and continuous monitoring.

How attackers use CT logs step by step

Attackers use CT logs during passive reconnaissance because the data is public and does not require touching the target's infrastructure.

The workflow is simple: search CT logs for a domain, extract DNS names, remove wildcard noise, deduplicate results, resolve live hosts, fingerprint services, and prioritize systems that look like staging, admin, API, VPN, dashboard, or cloud endpoints.

The same workflow is safe and useful for defenders when limited to owned or authorized domains.

Do not run active probing against third-party assets without permission.

• Step 1 — Query CT logs — Use crt.sh or another CT search source to pull certificate names for an owned domain. ```bash curl -s "https://crt.sh/?q=%25.example.com&output=json" \ | jq -r '.[].name_value' \ | sed 's/\*\.//g' \ | sort -u > ct-subdomains.txt ``` Expected output: ```text api.example.com admin-prod.example.com grafana-staging.example.com vpn-legacy.example.com www.example.com ```

• Step 2 — Resolve discovered names — Not every CT-discovered hostname is still live. Resolve the names before treating them as active assets. ```bash while read -r host; do ip=$(dig +short "$host" A | head -n 1) if [ -n "$ip" ]; then echo "$host $ip" fi done < ct-subdomains.txt > ct-live-hosts.txt ``` Expected output: ```text api.example.com 203.0.113.20 grafana-staging.example.com 203.0.113.45 vpn-legacy.example.com 203.0.113.70 ```

• Step 3 — Fingerprint HTTPS safely — For owned assets, collect basic HTTP status and headers without brute force or exploitation. ```bash while read -r host ip; do echo "### $host" curl -k -I --max-time 5 "https://$host" | head -n 8 done < ct-live-hosts.txt ``` Expected signals include status codes, server headers, redirects, HSTS presence, and obvious unauthenticated services.

• Step 4 — Prioritize risky names — Hostnames containing terms like admin, grafana, kibana, staging, dev, debug, vpn, ci, jenkins, backup, internal, legacy, or origin deserve review. Treat this as a review queue, not proof of vulnerability.

What attackers can do with CT-discovered subdomains

CT logs do not create the exposure. They reveal where to look.

The impact depends on what the discovered subdomain points to. A hardened production API is different from an unauthenticated dashboard, a stale vendor CNAME, or a staging app with weak access control.

The most common risk is attack-chain expansion. A hostname found through CT becomes the starting point for DNS checks, HTTP fingerprinting, takeover validation, service discovery, and configuration review.

Here are the practical consequences defenders should care about.

• Admin panel discovery — Names like admin, dashboard, grafana, kibana, jenkins, airflow, or portal can reveal management interfaces that were never meant to be broadly discoverable.

• Staging environment exposure — Staging and dev systems may run weaker authentication, debug settings, old dependencies, incomplete headers, or test data.

• Subdomain takeover candidates — A CT-discovered hostname may resolve to a third-party provider where the original resource was deleted. That is only a candidate until provider behavior and ownership are validated.

• Cloud and vendor discovery — Certificate names can reveal SaaS vendors, cloud regions, CDN providers, support portals, marketing tools, and documentation platforms.

• Origin bypass clues — Hostnames like origin, direct, old-lb, or legacy-api may reveal infrastructure that bypasses a CDN, WAF, or normal traffic path.

• Credential and session exposure — If CT-discovered systems expose logs, debug endpoints, backups, JavaScript secrets, or unauthenticated dashboards, attackers may find tokens, API keys, session material, or internal URLs.

How to detect CT-exposed subdomains

Start by treating CT logs as an external inventory source, not as a vulnerability scanner.

The goal is to answer four questions: what names have appeared in certificates, which names still resolve, which names expose services, and which names have no owner.

Run these checks only for domains you own or are authorized to assess.

Save results over time so you can detect new certificate-backed names instead of reviewing the same list repeatedly.

• Create a CT baseline — ```bash curl -s "https://crt.sh/?q=%25.example.com&output=json" \ | jq -r '.[].name_value' \ | sed 's/\*\.//g' \ | sort -u > baseline-ct-subdomains.txt ``` Review the output manually and assign owners to important names.

• Run a later comparison — ```bash curl -s "https://crt.sh/?q=%25.example.com&output=json" \ | jq -r '.[].name_value' \ | sed 's/\*\.//g' \ | sort -u > current-ct-subdomains.txt comm -13 baseline-ct-subdomains.txt current-ct-subdomains.txt > new-ct-subdomains.txt ``` Expected output: ```text new-api.example.com status-v2.example.com grafana-test.example.com ```

• Check for risky naming patterns — ```bash grep -Ei 'admin|dev|stage|staging|test|grafana|kibana|jenkins|vpn|debug|backup|internal|legacy|origin' current-ct-subdomains.txt ``` This does not prove a vulnerability. It creates a review queue.

• Check whether names still resolve — ```bash while read -r host; do if dig +short "$host" A | grep -qE '^[0-9.]+'; then echo "$host resolves" fi done < current-ct-subdomains.txt ```

• Check for stale CNAMEs — ```bash while read -r host; do cname=$(dig +short "$host" CNAME) if [ -n "$cname" ]; then echo "$host -> $cname" fi done < current-ct-subdomains.txt ``` Review CNAMEs pointing to old vendors, deleted apps, or services no team owns.

Remediation — exact fixes with safer certificate patterns

You cannot remove historical names from CT logs. Once a public certificate is logged, the entry is designed to remain publicly auditable.

Revoking a certificate can stop trust in a bad certificate, but it does not erase the hostname from CT history.

The practical fix is to reduce unnecessary future disclosure and harden the services that CT logs reveal.

Treat CT exposure as an asset-management and access-control problem.

• Before — sensitive hostnames in public certificates — ```text DNS:grafana-staging.example.com DNS:jenkins-dev.example.com DNS:vpn-legacy.example.com DNS:admin-prod.example.com ```

• After — neutral public names plus real access control — ```text DNS:app.example.com DNS:api.example.com DNS:status.example.com ``` Use neutral names where possible, but do not rely on names for security. Enforce authentication, network policy, and service ownership.

• Move internal-only systems away from public certificates — Internal-only systems should use private DNS and a private CA where appropriate. ```text Private DNS zone: grafana.platform.internal.example.com jenkins.build.internal.example.com ``` Do not request public CA certificates for services that should never be reachable from the public internet.

• Restrict exposed admin tools — If an admin tool must exist on the internet, restrict it explicitly. ```nginx location / { allow 203.0.113.0/24; deny all; proxy_pass http://grafana_backend; } ``` Do not rely only on IP allowlisting for admin tools. Combine it with SSO, MFA, least privilege, logging, and private access where possible.

• Remove stale DNS records — Before: ```dns grafana-staging.example.com. 300 IN CNAME old-grafana.vendor.example.net. ``` After: ```dns ; record removed after owner review ``` Do not leave DNS records pointing to deleted vendor resources, retired apps, or unknown cloud services.

• Monitor certificate issuance continuously — A one-time CT export becomes stale. Schedule CT comparisons after deployments, domain changes, vendor onboarding, and certificate automation changes.

Real-world incident: CT misissuance monitoring

Certificate Transparency was designed for accountability, not secrecy.

One of the most cited examples is the Symantec certificate misissuance issue involving Google-owned domains. Public CT monitoring helped surface certificates that should not have existed, and the event contributed to major browser and CA ecosystem changes.

This is not a subdomain-enumeration breach example. It is included because it proves CT's core security value: public certificate visibility changes what defenders and third parties can detect.

The same visibility also explains the reconnaissance tradeoff. If defenders can monitor public certificate names, attackers can monitor them too.

• Defensive lesson — Monitor CT logs for your own domains so unexpected certificates, new subdomains, and risky names are reviewed quickly.

• Operational lesson — Do not treat CT logs as private. Any name in a public certificate should be considered publicly discoverable.

• Security lesson — Do not rely on obscure subdomain names to protect staging systems, dashboards, VPN portals, or admin tools.

Where ExternalSight fits

ExternalSight includes certificate transparency and subdomain discovery as part of its external attack surface monitoring workflow for internet-facing domains.

For teams that want ongoing visibility, ExternalSight can monitor verified domains on supported plans and compare historical results for changes. That matters when new CT-backed subdomains appear after deployments, vendor onboarding, certificate automation, or cloud changes.

ExternalSight also combines CT evidence with related checks: DNS, TLS, HTTP headers, subdomain takeover candidates, exposed services, cloud exposure signals, passive DNS, issue classification, remediation planning, alerts, PDF export, JSON export on supported plans, and scan coverage reporting.

ExternalSight should not be treated as a guarantee of complete discovery or as a replacement for internal asset inventory, vulnerability management, WAF, SIEM, SOC, or penetration testing. It is useful because it turns public external evidence into a reviewable workflow for owned domains.