GSAN: Mining Subdomains from SSL Certificates Without Certificate Transparency Logs
Hook
While the security community obsesses over Certificate Transparency logs for subdomain enumeration, there’s an entire class of certificates they’ll never see: internal networks, self-signed certificates, and air-gapped infrastructure that don’t publish to public CT logs.
Context
Subdomain enumeration is foundational to modern penetration testing and attack surface mapping. For years, Certificate Transparency logs have been the go-to datasource—services like crt.sh and Censys aggregate billions of certificates, making subdomain discovery almost trivial for internet-facing domains. But this approach has a blind spot: it only works for certificates issued by public Certificate Authorities that participate in CT logging.
gsan (Get Subject Alternative Names) takes a different approach. Instead of querying centralized logs, it connects directly to HTTPS servers and extracts subdomains from the Subject Alternative Name (SAN) field in their SSL certificates. This matters because organizations frequently use self-signed certificates for internal tools, staging environments, and development servers. They deploy wildcard certificates that cover dozens of subdomains. They run services on non-standard ports. None of this infrastructure appears in Certificate Transparency logs, but the certificates themselves are still broadcasting valuable reconnaissance data to anyone who connects and asks.
Technical Insight
gsan is architecturally minimal—it appears to establish a TLS connection to the target server, retrieves the certificate during the TLS negotiation, and extracts DNS names from the SAN extension. This simplicity is a feature, not a limitation. By doing one thing well, gsan becomes trivially composable with Unix pipelines and other reconnaissance tools.
The basic invocation demonstrates this pipeline-first philosophy:
$ gsan microsoft.com
microsoft.com [126]:
- microsoft.com
- successionplanning.microsoft.com
- explore-security.microsoft.com
- wwwbeta.microsoft.com
- gigjam.microsoft.com
- mspartnerira.microsoft.comNotice the output format: plain text, one subdomain per line, prefixed with a hyphen. No JSON bloat, no XML verbosity. This is intentional—it makes the output trivially parsable by grep, awk, or any tool that expects line-delimited input. The bracketed number indicates how many SANs were found, giving you immediate feedback about certificate scope.
Where gsan truly shines is in batch processing scenarios. Because it reads from stdin and respects the IP:PORT format, you can chain it with network scanning tools like Shodan or nmap:
$ shodan search --fields ip_str,port --separator : --limit 100 https | \
cut -d : -f 1,2 | \
xargs gsan --timeout 1
207.21.195.58 [1]:
- orielstat.com
162.159.135.42 [4]:
- temp927.kinsta.cloud
- temp312.kinsta.cloud
34.230.178.151 [2]:
- procareltc.com
- clarest.comThis pipeline queries Shodan for HTTPS servers, extracts their IP addresses and ports, and feeds them to gsan with a 1-second timeout per connection. The timeout flag is critical here—when scanning hundreds of targets, you can’t afford to wait for slow or unresponsive servers.
The tool’s design choice to support both domain names and IP:PORT combinations is architecturally significant. Many HTTPS services run on non-standard ports (8443, 4443, or arbitrary high ports), and virtual hosting means multiple domains can share a single IP address. By connecting directly to specific IP:PORT combinations, gsan discovers certificates that DNS-based enumeration would miss entirely.
gsan also provides an --output flag that writes discovered subdomains to a file while still displaying results to stdout. This enables real-time monitoring while building an input list for downstream tools:
$ gsan microsoft.com --output microsoft.txt | nmap -iL microsoft.txtThis command extracts subdomains, writes them to a file, and immediately feeds that file to nmap for port scanning. You’re building a reconnaissance pipeline where each tool’s output becomes the next tool’s input—the Unix philosophy applied to offensive security.
The Docker containerization option is worth noting for operational security. When scanning targets from untrusted networks or analyzing potentially malicious certificates, running gsan in an isolated container limits exposure. The Docker image is published as francc3sco/gsan and works identically to the pipx installation:
$ cat domains.txt | xargs docker run --rm -i francc3sco/gsanThe --rm flag ensures containers are cleaned up after execution, and -i enables interactive mode for reading from stdin. This containerized approach is particularly valuable in CI/CD pipelines where you want reproducible scanning without installing Python dependencies on build agents.
Gotcha
gsan’s directness is both its strength and its weakness. Because it connects to each target individually, it’s inherently slower than querying Certificate Transparency logs. If you’re enumerating subdomains for 100 public internet domains, crt.sh will return results in seconds while gsan takes minutes.
The timeout handling, while configurable, requires manual tuning. Set your timeout too low and you’ll miss results from high-latency networks. Set it too high and unresponsive hosts will grind your scan to a halt. For large-scale scanning of thousands of hosts, you may need to wrap gsan with tools like GNU parallel to achieve concurrency.
More fundamentally, gsan only discovers what’s already in the certificate. If an organization uses separate certificates for each subdomain (instead of a wildcard or multi-domain certificate), you won’t discover sibling subdomains. The tool focuses specifically on certificate extraction rather than comprehensive validation or discovery.
Verdict
Use gsan if you’re testing internal networks, analyzing infrastructure that uses self-signed certificates, or need to verify what subdomains are actually declared in a specific server’s certificate rather than trusting historical CT log data. It’s ideal when you’re working with non-standard ports, have a list of IP addresses from network scanning, or want to integrate certificate inspection into automated security workflows. The pipeline-friendly design makes it perfect for chaining with Shodan, masscan, or custom reconnaissance scripts. Skip it if you’re only enumerating subdomains for public internet domains—Certificate Transparency log aggregators like crt.sh are orders of magnitude faster and more comprehensive for that use case. Also skip it if you need comprehensive subdomain enumeration from multiple sources (DNS brute-forcing, search engines, APIs); tools like subfinder or amass are better suited for that broader reconnaissance mission. gsan is a scalpel, not a Swiss Army knife—use it when precision certificate inspection is exactly what you need.
