Certificate Transparency logs for expiry tracking

A certificate transparency search shows every publicly logged TLS certificate for your domains, including notAfter dates and hostnames you forgot were in the SAN list—often days before browsers complain.

Security and platform teams use Certificate Transparency (CT) when they need inventory, not just a single live handshake. CT does not replace connecting to port 443, but it answers questions live TLS cannot: which CAs issued certs for *.example.com, whether a shadow environment got a cert last week, and which expirations cluster on the same Tuesday.

Most outages from expiry are not mystery bugs—they are names nobody tracked. Searching CT logs first gives you a paper trail of issuance and expiry without waiting for cron or a customer screenshot.

CT research also helps after acquisitions when nobody knows which certificate authority the acquired brand used last year. Instead of guessing from billing, query CT for the registrable domain and receive a timeline of issuers and serial numbers that finance can reconcile against invoices. Security reviews use the same export to prove no unexpected foreign CAs issued during transition windows.

Product marketing sometimes publishes microsites on agencies’ hosting without telling platform teams. Those sites still appear in public logs when agencies obtain DV certificates. A monthly certificate transparency search diff becomes a gentle discovery channel that is less intrusive than port scanning every IP in a range.

What to check

Separate three clocks when you read CT data. Certificate expiry is the notAfter on each logged leaf (and sometimes precerts). Trust and revocation still require live validation; CT tells you what was issued, not whether it is revoked today. Domain registration expiry is unrelated to CT but can block revalidation when you renew—pair CT host lists with RDAP domain expiration checks.

CT search is strongest for discovery: sub-brands, marketing microsites, old VPN gateways, and third-party SaaS vanity hosts. It is weaker for internal-only names that never hit a public CA log. After you build a hostname list from CT, confirm each critical endpoint with OpenSSL or a browser, as in OpenSSL certificate expiry date.

Note whether results are precertificates versus final certs, and whether duplicates differ only by serial or issuer. Duplicate rows for the same name often mean a renewal chain in progress or a mis-issued parallel cert you still serve somewhere.

Step-by-step

Use crt.sh (public CT mirror) from a shell, or the web UI for one-off review. Replace example.com with your registrable domain.

Query crt.sh for logged certificates

curl -s "https://crt.sh/?q=%25.example.com&output=json" \
  | jq -r '.[] | [.id, .not_after, .common_name, .issuer_name] | @tsv' \
  | sort -k2

For a specific hostname:

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

Extract soonest expirations (next 90 days)

curl -s "https://crt.sh/?q=%25.example.com&output=json" \
  | jq -r '.[].not_after' \
  | sort -u \
  | awk '$0 >= strftime("%Y-%m-%d", systime()) && $0 <= strftime("%Y-%m-%d", systime()+7776000)'

Cross-check a suspicious name on the wire

echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer

For graded trust and chain issues after you find a candidate in CT, run SSL Labs test expiry and grades on the same hostname.

Optional: Google CT API (programmatic)

Google’s https://ct.googleapis.com/logs/argon2024/ endpoints accept Merkle proofs; most teams stay with crt.sh unless they build monitors. Document API keys and rate limits if you automate.

How to read the output

Each crt.sh JSON row includes not_before, not_after, common_name, SAN text in name_value, and issuer_name. Sort by not_after to see renewal waves. A hostname with multiple future not_after values usually means overlapping issuances—only one is live on 443, but stale certs may still sit on another load balancer.

name_value blocks list every DNS name on the certificate. Wildcards appear as *.example.com; CT will not list unissued internal names. Compare CT not_after to OpenSSL notAfter= on the same host; if they differ by more than a few minutes, you are likely hitting a different terminator or an old binding.

Issuer strings identify the CA product (for example Let’s Encrypt R3 versus a corporate subordinate). When issuer changes between rows, plan intermediate updates on servers, not just leaf replacement.

Common mistakes

Treating CT as proof that production is healthy is the biggest error. Logs record issuance events; they do not show which cert nginx selected via SNI. Teams export a crt.sh CSV, alert on the oldest row, and miss the newer duplicate still expiring tomorrow on a forgotten IP.

Searching only the apex domain misses many certs issued solely to www or regional hosts. Use %25.example.com patterns and review SAN blobs, not just common_name.

Ignoring precertificate entries causes false urgency: precerts expire quickly by design. Filter to entries with usable leaf data or correlate serial numbers with live handshakes.

Finally, CT overload: popular domains return thousands of rows. Deduplicate by (name_value, not_after, issuer_name) before reporting to leadership. For incident response when a site is already broken, start with SSL certificate expired fix, then use CT to find siblings at risk.

Failing to record which CT mirror you queried weakens audit trails when mirrors diverge during maintenance. Store the full URL with URL-encoded domain patterns in your ticket system.

Teams sometimes confuse CT precertificates with customer-facing outages. Precerts expire quickly and never appear on production listeners; filter them when building executive summaries so you do not chase ghosts.

When to use automation

Manual certificate transparency search each quarter does not scale when marketing spins up dozens of hostnames. Automate nightly crt.sh queries (or commercial CT feeds) into a database keyed by registrable domain, dedupe SANs, and diff new issuances against your CMDB.

Pair CT-derived not_after lists with live TLS probes on the hostnames that matter for revenue and email. CT finds candidates; port 443 confirms reality. Add RDAP registrar expiry so OV renewals and DNS validation do not fail for billing reasons.

Schedule alerts at 30, 14, and 7 days before the earliest live notAfter per hostname, not merely the oldest CT row. External monitoring (for example a free check on ssldays) catches drift when CT shows a fresh cert but one edge POP still serves the previous PEM file.

Build a lightweight CT review calendar: after major releases, search logs for the release hostname pattern and attach top findings to the retro. Train support engineers to run crt.sh before escalating “certificate looks wrong” tickets—many turn out to be stale intermediate chains on one POP, not calendar expiry.

When exporting CT JSON into spreadsheets, store the query URL and timestamp in the filename. Auditors ask whether data was current at decision time. Encrypted note columns for owner team and renewal method turn passive inventory into actionable workflow without another SaaS SKU.

Regulated industries sometimes prohibit storing full SAN lists in third-party tools. In that case, run CT queries inside your VPC and redact before sharing externally, but do not skip discovery entirely—internal hosting often surprises you with forgotten vanity domains tied to old campaigns.

Journalists and researchers frequently cite CT when covering phishing campaigns; proactive communications teams should monitor CT diffs for brand-adjacent labels and route suspicious issuances to security operations before social media amplification.

University research networks generate noisy CT entries from student experiments; filter academic sandbox domains in reporting so central IT focuses on production finance and identity systems rather than ephemeral lab hosts.

When negotiating with certificate management vendors, ask whether their inventory feeds include CT supplementation or rely solely on agent software. Gaps in either direction change how much you trust vendor dashboards during due diligence.

Board members rarely want raw JSON; translate CT findings into bar charts of expiries by month and top ten unexpected issuers. Visual summaries secure funding for renewal automation better than terminal screenshots.

Plan for crt.sh maintenance windows by maintaining offline archives of last successful query results. Discovery pipelines should degrade gracefully, queueing retries instead of silently assuming no new certificates appeared.

Assign a rotating CT review owner each sprint so discovery does not depend on one senior engineer’s memory. Handoffs include last query URLs, open anomalies, and linked renewal tickets for any hostname expiring inside forty-five days.