Certificate Transparency Cartography

At 17:59 on a Tuesday, I ran nmap against the network. What I found was educational.

The Routine Scan

Management had requested—in that special way they request things that mean "do it or explain why not in writing"—a comprehensive network security audit. I complied. Thoroughly.

$ nmap -sS -p 443,8443 --script ssl-cert 192.0.2.0/24
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-10-27 17:59 CET

Standard reconnaissance. SYN scan, common HTTPS ports, certificate enumeration. The kind of thing you run before morning coffee. Except this time, the certificates had opinions about organizational structure.

The scan completed in forty-seven seconds. The results took considerably longer to process. Not because of technical complexity—because of the sheer comedic value of what our certificates were confessing to the internet.

Subject Alternative Names. SANs. Those helpful little fields that tell browsers, "Oh, this certificate is also valid for these seventeen other hostnames you didn't know existed."

Transparency is a virtue. Unless you're trying to obscure your internal infrastructure.

The Reconnaissance Revelation

I pulled up the results and started mapping. Each certificate was a confession.

$ nmap -p 443 --script ssl-cert 192.0.2.15

443/tcp open  https
| ssl-cert: Subject: CN=prod-web-01.megacorp.example
| Subject Alternative Name:
|   DNS:prod-web-01.megacorp.example
|   DNS:prod-web-01.internal.megacorp.example
|   DNS:web-legacy-do-not-touch.megacorp.example
|   DNS:jenkins-staging-maybe-production.megacorp.example
|   DNS:backup-web-server-from-2019.megacorp.example

Beautiful. A single certificate advertising five hostnames, three of which Management didn't know existed, and one that explicitly contradicted our infrastructure documentation.

I documented this. For posterity.

The TTY wandered over, looked at my screen, and asked the question I'd been waiting for.

TTY: "Should certificates... tell people all that?"

The TTY is learning.

I ran the scan across the entire subnet. Certificate Transparency logs—publicly searchable databases of every certificate ever issued by major CAs—meant I could cross-reference what our servers claimed to be with what they'd told the internet they were.

#!/bin/bash
# The Operator's Certificate Cartography Script
for ip in 192.0.2.{1..254}; do
  echo "Scanning $ip..."
  nmap -p 443,8443,8080 --script ssl-cert $ip | \
    grep -A 20 "Subject Alternative Name" | \
    tee -a /tmp/certificate-inventory.txt
done

The results assembled themselves into a complete network map. Internal hostnames. Development servers. That test database Management swore we'd decommissioned in 2022. A server literally named definitely-not-production.internal.megacorp.example that was, according to its certificate, absolutely production.

Reconnaissance doesn't require sophisticated attacks when your infrastructure volunteers.

The Educational Documentation

I created a visual network topology map. From certificates. Publicly available certificates. The kind anyone with nmap and twenty minutes could enumerate.

The certificate for 192.0.2.42 was particularly generous:

Subject Alternative Name:
  DNS:admin-panel.megacorp.example
  DNS:admin.internal.megacorp.example
  DNS:admin-backup.internal.megacorp.example
  DNS:secret-admin-dont-tell-security.megacorp.example

Someone—I suspected the previous sysadmin, who'd left "to pursue opportunities in agriculture"—had a unique approach to certificate management. That approach was: put everything in one certificate and hope nobody notices.

I sent the TTY to investigate secret-admin-dont-tell-security.megacorp.example. They returned fourteen minutes later with a fascinating report: it was an unsecured admin panel for our production database. No authentication. Just a cheerful login prompt that accepted any credentials.

The TTY gestured vaguely toward fixing it.

TTY: "Should I...?"

OPERATOR: "First, document exactly how you found it. Then document what you would have found if you were someone less friendly. Then we discuss this with Management. With detailed documentation."

Strategic compliance through thorough reporting.

The Comprehensive Report

I compiled the findings into a report. Management had requested a security audit. I provided a security audit.

Findings:

• 47 servers with certificates advertising internal hostnames
• 12 servers with SANs containing the word "secret," "hidden," or "backup"
• 1 server whose certificate revealed it was both staging and production simultaneously
• 0 servers that followed certificate naming conventions from our (apparently theoretical) security policy

Methodology:

• Basic nmap scan (12 lines of bash)
• Certificate Transparency log correlation (publicly available data)
• DNS reconnaissance (standard network enumeration)
• Time investment: 47 minutes
• Coffee consumed: 2 cups

Recommendations:

• Wildcard certificates for internal services (stop advertising topology)
• Internal CA for private hostnames (stop telling Certificate Transparency logs everything)
• Rename secret-admin-dont-tell-security.megacorp.example (stop doing that)
• Review certificate SANs before issuance (revolutionary concept)

I sent the report to Management at 09:00 the following morning—the optimal time for delivering concerning news after they've had coffee but before they've built momentum on other tasks.

Resolution & New Policies

Management responded with impressive speed. By 14:30, they'd implemented a new policy: all certificate requests required security review before issuance.

The TTY was assigned to help implement proper certificate management. A learning opportunity. They'd discovered the admin panel; now they could learn about fixing the infrastructure that exposed it.

TTY: "What if someone had found this before us?"

OPERATOR: "Then we'd be having a different conversation. Probably with lawyers. Document everything you do. This is how we prevent the next incident."

The network map I'd generated from certificates alone now lived in our internal wiki. Under "Examples of What Not to Do." Management had suggested calling it "Historical Infrastructure Decisions." I'd labeled it "Certificate Transparency: A Case Study in Accidental Disclosure."

The servers were recertified with proper naming conventions. Internal hostnames moved to an internal CA. The admin panel was secured, audited, and renamed to something that didn't advertise its function to anyone with nmap.

Uptime remained unaffected throughout. The infrastructure didn't know it had been confessing to the internet. The certificates didn't know they'd betrayed organizational secrets. And Management now understood that "publicly trusted certificate" means public.

The Operator's Notes

The moral: certificates remember everything and tell everyone. Subject Alternative Names are helpful for browsers, less helpful for operational security. The TTY learned about certificate management, DNS reconnaissance, and the importance of naming conventions. Management learned that security audits sometimes reveal more than anticipated.

Certificate Transparency logs: 100% available. Network topology: 100% documented. Coffee consumed during this investigation: immeasurable. The admin panel is now secured. The certificates now lie properly. Such is infrastructure.

Documented for posterity. And for the next audit. Which will probably find something else.