cero: extracting hostnames from TLS certificates
cero · MIT
cero connects to hosts, reads the TLS certificate, and prints the names in it. That is the whole tool. It is a discovery technique rather than an inspection one: certificates name hostnames, and organisations put internal names in public certificates constantly.
Install
go install github.com/glebarez/cero@latestCore commands
# a single host
cero example.com
# a CIDR — scrape certificates off an entire range
cero 10.0.0.0/24
# non-default ports
cero -p 443,8443,9443 example.com
# concurrency and timeout for larger sweeps
cero -c 200 -t 4 -d example.com < targets.txt-d restricts output to names within the given domain, which is how you keep results in scope.
Output
One hostname per line, extracted from certificate CN and SAN fields:
example.com
www.example.com
internal-api.example.com
vpn-gw.example.comWhere it sits in Tandera
cero runs in discovery on recon_web_lite and recon_web_full, as the third passive subdomain producer alongside subfinder and findomain.
It contributes something the other two structurally cannot. subfinder and findomain query databases of names other people already collected. cero reads the certificate presented by the host in front of it, right now — which is how it finds names that were never logged publicly, never linked, and never resolved from outside.
Using it in a pentest
Point it at IP ranges, not just domains. Sweeping a client’s netblock with cero surfaces the naming of everything terminating TLS in it. This is often the single highest-yield discovery step against an organisation with its own address space.
Always use -d. Shared hosting and load balancers present certificates covering many customers. Without a domain filter you will collect hostnames belonging to companies who are not your client.
Internal names in public certificates are worth reporting. Even when the host is unreachable, publishing vpn-gw.corp.internal in a public certificate is an information-disclosure finding in its own right.