I Scanned a Company's Public Certificates — Here's What I Found

What Certificate Transparency Logs Actually Tell You

Every public certificate issued by a trusted Certificate Authority gets logged in Certificate Transparency (CT) logs. This means anyone — including you — can query these logs to see every certificate ever issued for a domain.

Most security teams don’t realize how much information is publicly available about their certificate infrastructure. I ran a scan against a mid-size enterprise (with permission) and the results were eye-opening.

Here’s what I found, how I found it, and what you should do about similar findings in your own environment.

The Scanning Methodology

I used a combination of three approaches to build a complete picture:

1. Certificate Transparency Log Queries

# Query crt.sh for all certificates issued for a domain
curl -s "https://crt.sh/?q=%.example.com&output=json" | \
  jq -r '.[].common_name' | sort -u

This single query returned 847 unique certificate entries spanning 6 years of issuance history.

2. Active Certificate Scanning

# Scan discovered subdomains for their current certificates
echo "subdomain.example.com" | \
  xargs -I {} openssl s_client -connect {}:443 -servername {} \
  </dev/null 2>/dev/null | \
  openssl x509 -noout -dates -subject -issuer

3. DNS Enumeration Cross-Reference

# Cross-reference CT findings with DNS records
subfinder -d example.com -silent | \
  httpx -silent -tls-grab -json | \
  jq '{host: .host, issuer: .tls.issuer_organization, expiry: .tls.not_after}'

What the Scan Revealed

The Certificate Visibility Gap

Typical enterprise: what's tracked vs. what actually exists

Tracking Coverage

Certificates Found by Source

⚠️ In the average mid-market enterprise, less than 15% of certificates have both ownership documentation and expiry monitoring.

Finding #1: 23 Expired Certificates Still Serving Traffic

Of the 312 active endpoints discovered, 23 (7.4%) were serving expired certificates. These weren’t just test environments — several were customer-facing services.

Service Type	Count	Avg. Days Expired	Risk Level
Customer portals	4	12 days	Critical
API endpoints	7	34 days	High
Internal tools (public-facing)	8	67 days	Medium
Dev/staging environments	4	120+ days	Low

Finding #2: Weak Cryptographic Algorithms

Certificate Analysis Summary:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
RSA 2048-bit:     187 certificates (60%)
RSA 4096-bit:      62 certificates (20%)
ECDSA P-256:       41 certificates (13%)
RSA 1024-bit:      14 certificates (5%)   ⚠️ WEAK
SHA-1 signatures:   8 certificates (3%)   ⚠️ DEPRECATED

14 certificates were still using RSA 1024-bit keys, which have been considered insecure since 2013. Eight certificates had SHA-1 signatures, deprecated by all major browsers since 2017.

Finding #3: Shadow Domains and Forgotten Services

CT logs revealed certificates for subdomains that the IT team didn’t know existed:

# Unexpected subdomains found in CT logs
old-vpn.example.com          - Cert issued 2021, no DNS record
staging-api-v2.example.com   - Cert issued 2022, still resolving
partner-portal.example.com   - Cert issued 2020, expired 2021
m.example.com                - Cert issued 2019, mobile site abandoned
legacy-sso.example.com       - Cert issued 2020, old SSO provider

These represent forgotten infrastructure — services that were spun up, possibly decommissioned, but never properly cleaned up. Each is a potential attack surface.

Finding #4: Certificate Authority Sprawl

The organization was using 7 different Certificate Authorities with no apparent governance:

CA Provider	Cert Count	% of Total	Managed By
DigiCert	89	29%	Security team
Let’s Encrypt	112	36%	DevOps (automated)
Sectigo	34	11%	IT operations
GoDaddy	28	9%	Marketing team
AWS ACM	31	10%	Cloud team
GlobalSign	12	4%	Legacy
Self-signed	6	2%	Unknown

No single team had visibility into the full certificate landscape.

Finding #5: Wildcard Certificate Overuse

Wildcard certificates found: 18
Covering unique subdomains:  340+

Risk: A single wildcard private key compromise 
      exposes ALL services under that domain.

Wildcard certificates were deployed to 18 different servers, meaning the private key existed in at least 18 locations. If any single server is compromised, every service under *.example.com is at risk.

The Risk Scoring Framework

I categorized findings using a simple risk matrix:

CRITICAL (Score 9-10):
  - Expired certs on customer-facing services
  - SHA-1 certs handling sensitive data
  - Wildcard keys on internet-facing servers

HIGH (Score 7-8):
  - Expired certs on internal-but-reachable services
  - RSA 1024-bit keys
  - Unknown/unmanaged CAs issuing for your domain

MEDIUM (Score 4-6):
  - Expired certs on internal-only services
  - Shadow domains with valid certificates
  - CA sprawl without governance

LOW (Score 1-3):
  - Expired certs in non-production environments
  - Short-lived certs approaching expiry (within policy)
  - Documentation gaps

How to Run This Scan Yourself

Step 1: CT Log Query

#!/bin/bash
# scan-ct-logs.sh - Query CT logs for your domain
DOMAIN="yourcompany.com"

echo "[*] Querying crt.sh for $DOMAIN..."
curl -s "https://crt.sh/?q=%.$DOMAIN&output=json" | \
  jq -r '.[].common_name' | \
  sort -u > ct-domains.txt

echo "[*] Found $(wc -l < ct-domains.txt) unique entries"
echo "[*] Checking for wildcard certs..."
grep '^\*\.' ct-domains.txt

Step 2: Active Endpoint Scanning

#!/bin/bash
# check-cert-status.sh - Verify active certificates
while read domain; do
  result=$(echo | timeout 5 openssl s_client -connect "$domain:443" \
    -servername "$domain" 2>/dev/null | \
    openssl x509 -noout -enddate 2>/dev/null)
  
  if [ -n "$result" ]; then
    expiry=$(echo "$result" | cut -d= -f2)
    expiry_epoch=$(date -d "$expiry" +%s 2>/dev/null)
    now_epoch=$(date +%s)
    days_left=$(( (expiry_epoch - now_epoch) / 86400 ))
    
    if [ $days_left -lt 0 ]; then
      echo "EXPIRED ($days_left days): $domain"
    elif [ $days_left -lt 30 ]; then
      echo "WARNING ($days_left days): $domain"
    fi
  fi
done < ct-domains.txt

Step 3: Algorithm Analysis

#!/bin/bash
# check-algorithms.sh - Identify weak crypto
while read domain; do
  cert_info=$(echo | timeout 5 openssl s_client -connect "$domain:443" \
    -servername "$domain" 2>/dev/null | \
    openssl x509 -noout -text 2>/dev/null)
  
  # Check key size
  key_size=$(echo "$cert_info" | grep "Public-Key:" | grep -oP '\d+')
  if [ "$key_size" -lt 2048 ] 2>/dev/null; then
    echo "WEAK KEY ($key_size-bit): $domain"
  fi
  
  # Check signature algorithm
  sig_algo=$(echo "$cert_info" | grep "Signature Algorithm:" | head -1)
  if echo "$sig_algo" | grep -q "sha1"; then
    echo "SHA-1 DETECTED: $domain"
  fi
done < ct-domains.txt

Remediation Priority Matrix

Based on the findings, here’s the remediation plan I recommended:

Immediate (Week 1)

Action	Impact	Effort
Replace expired customer-facing certs	Critical risk removal	2-4 hours
Rotate compromised wildcard keys	Eliminate key exposure	4-8 hours
Disable SHA-1 certificate endpoints	Compliance alignment	1-2 hours

Short-term (Month 1)

Action	Impact	Effort
Migrate RSA 1024 to 2048+	Algorithm compliance	1-2 days
Decommission shadow domains	Reduce attack surface	2-3 days
Consolidate CA providers	Simplify management	1 week

Long-term (Quarter 1)

Action	Impact	Effort
Implement CLM platform	Full visibility	2-4 weeks
Establish certificate governance	Prevent recurrence	Ongoing
Automate renewal workflows	Eliminate manual risk	2-3 weeks

Key Takeaways

1. Public certificates are public — anyone can see what you have issued via CT logs
2. Shadow infrastructure accumulates — without active scanning, forgotten services multiply
3. CA sprawl is governance failure — multiple teams buying certificates independently means nobody owns the problem
4. Weak algorithms persist — organizations rarely proactively upgrade crypto unless forced
5. Scanning is step one — discovery without remediation and ongoing monitoring is just a one-time snapshot

What This Means for Your Organization

If you haven’t scanned your own public certificate landscape, you likely have similar findings. The question isn’t whether you have certificate visibility gaps — it’s how many, and which ones are actively creating risk.

The tools shown here are free and accessible. The scan takes <2 hours to run. The findings, however, often take weeks or months to fully remediate — which is exactly why starting with discovery is so important.

---

About QCecuring

QCecuring provides certificate lifecycle management and PKI solutions that give enterprises complete visibility into their certificate landscape. Our platform automates discovery, monitors expiry, and ensures no certificate goes unmanaged — whether it’s public, internal, or somewhere in between.

Tags: certificate discovery, CT logs, certificate scanning, expired certificates, weak algorithms, shadow domains, enterprise security, certificate visibility, PKI governance, remediation planning