2026-10-30 · RESEARCH · The Offensive Technology team

Does a Wildcard Certificate Hide Your Subdomains?

Does a wildcard certificate hide your subdomains? Mostly, but almost nobody actually uses one that way. We read the current, live certificate for 660 top domains through the same public Certificate Transparency logs anyone can query, and classified what each one discloses. 63.8% enumerate at least one real subdomain by name in plain SAN entries, with no wildcard protection at all. Only 22.9% rely purely on a wildcard, hiding their subdomain structure the way the technology allows. Add the 11.1% that do both at once, and 74.8% of current certs on top domains disclose a specific hostname, whether or not they also hold a wildcard. A wildcard genuinely works as designed. Almost nobody chooses it for that reason.

Why this is a decision, not just a default

Wildcard and SAN (Subject Alternative Name) certificates solve the same problem, covering more than one hostname with one certificate, in opposite ways. A wildcard matches a pattern: *.example.com is valid for any single-level name under example.com, without that name ever appearing on the certificate itself. A SAN certificate instead lists hostnames explicitly, one certificate can cover app.example.com, api.example.com, and admin.example.com by writing all three into the SAN field. Both are standard, both are issued by every public CA, and the certificate's subject does not reveal which approach was a deliberate choice versus an accident of tooling.

The accident is the common case. Free automated issuance, the kind almost every modern deployment uses, typically requests a certificate for the exact hostname a server is configured with. Spin up ten subdomains with ten separate automated certificate requests, and you get ten SAN certificates, each one logging its own name, never a single wildcard covering all ten. Choosing a wildcard instead is an extra step most teams never take, because the default path already produces a working certificate.

The data: what 660 current certs actually choose

For each of 660 top domains with any Certificate Transparency history, we took the most recent certificate already in our local cache (zero new requests to crt.sh this run, reusing the dataset from three prior research posts) and read its Subject and SAN fields. We classified each certificate by what it discloses beyond the boring, universal pair of the bare domain and its www. address: a wildcard entry with nothing else, a wildcard plus named hostnames, named hostnames with no wildcard at all, or neither.

Amber bars disclose a specific hostname somewhere on the certificate; teal bars do not. Only the 22.9% wildcard-only slice and the 2.3% apex-only slice, 25.2% of the sample combined, keep their subdomain naming out of the public record. The other three in four domains are, right now, giving away at least one real subdomain name to anyone who reads Certificate Transparency.

It is rarely just one name

Once a certificate discloses anything, it tends to disclose more than a single stray hostname. Among the 494 certificates that named at least one specific subdomain, the typical case lists just one or two, but the distribution has a long tail: the busiest single certificate in the sample enumerates 70 distinct subdomains, and 20 certificates (4.0% of all disclosing certs) list ten or more, with 9 of those listing 25 or more. A certificate that size is not hiding anything, it is closer to a public sitemap of an organization's infrastructure, issued in one request and logged in one record.

That last row is worth sitting with. One certificate in the "mixed" bucket carries 94 distinct wildcard entries on a single key, alongside named SANs. That is almost certainly a platform or SaaS provider wildcarding coverage for many customer or regional subdomains at once. It is efficient to operate. It also means one private key, if it is ever stolen, is valid for every subdomain under all 94 of those patterns simultaneously, present and future. Wildcarding trades subdomain secrecy for a different risk: how much blast radius sits behind one key.

Why not everyone just uses a wildcard

If a wildcard hides more, why does only 22.9% of the sample use one exclusively? A few practical reasons, none of them a mistake in isolation:

• Automation defaults to naming, not wildcarding. Tools like Certbot request a certificate for the hostname a server already answers to. Getting a wildcard instead means proving domain control via a DNS-01 challenge, an extra step with extra tooling most deployments skip.
• A wildcard only covers one level. *.example.com matches app.example.com but not a.app.example.com. Any real second-level hierarchy needs either a second wildcard or named entries, which pulls organizations back toward enumeration even when they already hold a wildcard.
• Key-compromise blast radius is real. One wildcard private key, once exposed, impersonates every subdomain it covers at once. A compromised per-host key only ever covered that one host. Teams running sensitive, separately-owned subdomains sometimes choose named certificates specifically to keep that blast radius small, even though it costs them subdomain secrecy.
• Some audits want to see explicit coverage. A few compliance and inventory processes are easier to run against a certificate that lists every covered hostname by name than one that asserts coverage via a pattern.

How to check your own domain

This takes under a minute and needs nothing beyond a browser, because it is reading the same public record we read.

• Query crt.sh for your current certificate. Open https://crt.sh/?q=yourdomain.com&output=json and look at the most recent entry's name_value field, or check your server's certificate directly with openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name".
• Count what it actually discloses. A single *.yourdomain.com entry with nothing else is wildcard-only. Anything else, any named host beyond the bare domain and www., is already public via CT, whether or not you also hold a wildcard elsewhere.
• Decide the tradeoff deliberately. If subdomain secrecy matters more than key-compromise blast radius for your architecture, move toward a wildcard and a DNS-01 issuance flow. If it does not, at minimum treat every named SAN as permanently public and stop relying on an unnamed subdomain as a form of security.

What this does not prove

Honest limits, because a number without its caveats is marketing.

• We read the most recent certificate per domain, not its full history. A domain could have used a wildcard for years and only recently added a named SAN, or vice versa. This is a snapshot of current disclosure, not a lifetime pattern.
• A named SAN is not proof the service behind it is live or reachable. We classified hostname text on a certificate, nothing else. Some named subdomains may point at infrastructure that no longer exists.
• It is a 660-domain sample of large, established sites. Tranco's top-sites ranking skews toward organizations with enough infrastructure to need more than one hostname in the first place. A different population would shift the exact split.
• This measures disclosure, not exploitability. Knowing a subdomain's name is reconnaissance. What an attacker does with that name depends entirely on what is actually running behind it.

Frequently asked questions

Does a wildcard certificate hide subdomains?

Partially. A wildcard for *.example.com logs only the wildcard string, not specific labels. But in our sample, 63.8% of current certs name a real subdomain regardless, and only 22.9% rely purely on a wildcard with no named host exposed.

Can subdomains covered by a wildcard still appear in Certificate Transparency logs?

The wildcard entry itself appears only as the pattern, not a specific name. But the moment a separate certificate names a host explicitly, that name is logged in full, even alongside an existing wildcard. 11.1% of the certs here do both.

What is the difference between a wildcard and a SAN certificate?

A wildcard covers a pattern, *.example.com, without naming any subdomain. A SAN certificate lists specific hostnames explicitly. Automated issuance defaults to SAN certificates for the exact hostname a server runs, which is why enumeration, not wildcarding, is the common case.

Is a wildcard certificate more secure than listing each subdomain explicitly?

For subdomain-name secrecy, yes. For key-compromise blast radius, not necessarily: one stolen wildcard key is valid for every subdomain it covers at once, where a compromised per-host key only covers that host.

What happens if a wildcard certificate's private key is compromised?

An attacker can impersonate any subdomain under that pattern until the certificate is revoked and reissued everywhere it was deployed. One certificate in our sample carries 94 distinct wildcard entries on a single key, a wide blast radius if that key is ever exposed.

Does a wildcard cover subdomains of subdomains?

No. *.example.com matches a.example.com but not a.b.example.com. A second-level name needs its own wildcard or an explicit SAN entry, one reason organizations enumerate hostnames even when they also hold a wildcard.

How do attackers use Certificate Transparency logs to enumerate subdomains from SAN lists?

Every certificate a public CA issues is logged under RFC 6962 and searchable for free through crt.sh. A certificate that enumerates hostnames by name hands an attacker a ready-made subdomain map, no scanning required.

Should you choose wildcard or SAN for security, not just convenience?

If subdomain-naming secrecy matters, a wildcard is the stronger default, and most organizations in this sample are not making that choice. If you enumerate, treat every named SAN as permanently public, and weigh the key-compromise tradeoff before switching.

Related reading

• How Certificate Transparency logs leak internal subdomains Same cache, the content question: what categories of internal hostname actually show up once a cert discloses one.
• How long does it take a certificate to show up in CT? Same crt.sh wheelhouse, the timing question instead of the disclosure question.
• Has the 200-day certificate rule already taken effect? A third angle on the same 660-domain cache: how long certs are allowed to live, not what they disclose.