Wildcard Certificates: 28.5% of the TLS Web on One Key
Published
Figures as of 16 August 2026 · methodology v9. This is a recurring report; each edition re-measures the same population so the numbers can be tracked over time. All figures are aggregate — we never publish an individual business’s grade or name an individual registrant’s domain.
The headline: more than one in four TLS certificates is a wildcard
Of the 231,455,163 TLS certificate observations in our August 2026 census, 66,011,927 — 28.5% — were wildcard certificates. One certificate, one private key, valid for every subdomain under the name. Not the login portal specifically, or the API specifically, or the mail interface specifically. All of them, including the subdomains that don’t exist yet.
Put the same figure against the whole graded population and it gets starker: 17.5% of all 376.9 million graded domains in the census present a wildcard certificate on their web front door. Nearly one in six of the measured internet has decided that one key should cover everything.
That is not automatically a mistake. Wildcards are cheap, convenient, and in some architectures the only practical option. But it is a shared-fate decision, made 66 million times, and mostly made by default rather than by anyone weighing the trade. This report puts a number on how far the wildcard model has spread, and explains what actually rides on that one key.
Key numbers
- 28.5% of TLS certificate observations are wildcards: 66,011,927 of 231,455,163 in the August 2026 census.
- 71.5% are named (non-wildcard) certificates: 146,013,938 observations — roughly 2.2 named certs for every wildcard.
- 17.5% of all 376.9 million graded domains present a wildcard certificate at their apex.
- A wildcard certificate is valid for every first-level subdomain of its name, existing or not — one private key covers the whole namespace level.
- Let’s Encrypt is the census’s largest certificate issuer at 116.3 million observations (50.2% of domains presenting a certificate), and has issued free wildcard certificates since March 2018 (issuance date is industry knowledge, not census data).
What is a wildcard certificate?
A named certificate says: this key speaks for www.example.com, and perhaps a short list of other names spelled out one by one. A wildcard certificate says: this key speaks for *.example.com — anything at that level. shop.example.com, mail.example.com, internal-staging-do-not-index.example.com. Any label anyone puts in front of the dot, forever, until the certificate expires.
The appeal is obvious. One certificate to buy or automate, one renewal to babysit, no re-issuance every time the business spins up a new subdomain. For a SaaS platform giving each customer their own subdomain, or a CDN terminating TLS for thousands of hostnames, per-name certificates at scale used to be genuinely painful. The wildcard was the pressure valve.
The cost is concentration. Every hostname a wildcard covers is only as safe as the one private key behind it. Which brings us to shared fate.
How much of the web runs on wildcard certificates?
The census-wide split, from 231.5 million certificate observations across the graded population:
| Certificate kind | Observations | Share of TLS web |
|---|---|---|
| Wildcard | 66,011,927 | 28.5% |
| Named (specific hostnames) | 146,013,938 | 71.5% |
| Total | 231,455,163 | 100% |
Two readings of the same table. The optimistic one: more than two thirds of the TLS web still scopes its certificates to named hosts, which is the tighter practice. The other one: wildcard deployment at 66 million domains means the shared-key model is not a niche convenience for big multi-tenant platforms. It is more than a quarter of everything.
One measurement note before anyone lifts that 28.5%: these are per-domain observations, not distinct certificates. Each graded domain contributes the certificate it presented when we connected. A single wildcard certificate deployed across many domains (a hosting provider’s shared cert, say) counts once per domain that served it. The figure answers “what share of domains sit behind a wildcard?”, not “what share of issued certificates are wildcards?”. For the shared-fate question, the per-domain view is the one that matters.
Why does one key for every subdomain matter?
Because a wildcard converts a local compromise into a namespace-wide one.
With named certificates, stealing the key for the marketing site gets an attacker the marketing site. The login portal, the API, the webmail run on different keys; each is a separate theft. With a wildcard, the blast radius is the whole level of the namespace. Whoever holds that one key can impersonate any subdomain the organisation has — and any subdomain it doesn’t have, which is the part people forget. account-verify.example.com never needs to have existed for a phishing page presenting the stolen wildcard cert to validate perfectly in every browser.
The key’s exposure also multiplies with deployment. A named certificate for one service lives on that service’s servers. A wildcard, by design, gets copied to every box that terminates TLS for any covered subdomain: the web tier, the mail interface, the staging environment, the third-party service someone CNAMEd in. Each copy is another place the key can leak from, and the least-hardened machine in that list sets the security of all of them. Security agencies have warned about exactly this concentration risk — the NSA published guidance in 2021 urging organisations to scope certificates narrowly for this reason (the advisory is industry knowledge, not census data).
None of this makes the 66 million wildcard deployments wrong. A single-server setup serving www and blog from the same machine loses little to a wildcard, because the key was on one box either way. The problem is that the census can’t tell the deliberate deployments from the defaults, and neither, we suspect, can many of the deployers. A wildcard is a fine tool chosen; it is a quiet liability inherited.
Why did the wildcard web get this big?
Three forces, compounding.
Price collapsed. Wildcards were once a premium product costing several hundred dollars a year against tens for a single name (historical pricing is industry knowledge). Let’s Encrypt began issuing wildcard certificates free of charge in March 2018, via DNS-01 validation. The moment the price gap hit zero, the calculus for a lot of admins became “why would I not take the cert that covers everything?” Let’s Encrypt is the largest issuer in our census at 116.3 million certificate observations — 50.2% of domains presenting a certificate — so its issuance defaults shape the whole distribution.
Platforms deploy them for you. A large share of the web no longer configures its own TLS. Hosting panels, CDNs and SaaS platforms terminate TLS on the customer’s behalf, and at multi-tenant scale wildcard and shared certificates are the operationally sane choice. Millions of the wildcard observations in our data are a platform’s architecture decision, not the domain owner’s.
Automation lagged the alternative. The tight-scoped alternative — a certificate per hostname, renewed automatically — only became painless with mature ACME tooling. Organisations that adopted their wildcard habit in the manual era had no reason to revisit it once renewals were automated. The wildcard survived the death of its original justification.
The result is the number in the table: a shared-fate model, chosen mostly on convenience grounds in an era when the alternative was expensive, now covering more than a quarter of the TLS web in an era when it no longer is.
What tighter practice looks like
For anyone re-examining an inherited wildcard, the trade is worth stating plainly, because the fix costs nothing but attention.
Scope certificates to the hostnames that exist. ACME automation makes per-name issuance and renewal effectively free, and a leaked key then exposes one service instead of a namespace. Where a wildcard is genuinely the right call — multi-tenant platforms, dynamic subdomain products — treat the key accordingly: keep it on as few machines as possible, and prefer issuing distinct wildcards per environment over copying one everywhere. And publish a CAA record either way, so only your chosen CA can issue for your name at all.
That is the recurring theme of this census: the gap between weak and strong configurations is rarely money. It is that nobody told the owner the default carried a trade-off.
How we measured this
- Population: the August 2026 census round — 432 million domains scanned, 376,928,781 graded. Figures as of 16 August 2026, methodology v9.
- Denominator: 231,455,163 graded domains that presented a TLS certificate on our web probe.
- Wildcard detection is string-based. A certificate was classified as wildcard when its subject common name or subject alternative names contained a wildcard label (
*.). We did not semantically validate the wildcard’s scope or match it against the probed hostname. String matching is robust for this classification, but it is a syntactic test, and we label it as such. - Per-domain observations, not distinct certificates. Each graded domain contributes one observation: the leaf certificate it served us. Shared certificates deployed across many domains are counted once per domain. Shares answer “what fraction of domains sit behind a wildcard?”.
- Leaf certificate only, at capture time. We record what the domain’s web endpoint presented during the census window, from our EU measurement infrastructure — a single vantage. Certificates served only on specific subdomains we did not probe are outside the frame; the census observes the domain’s front door.
- Issuer figures come from the same round’s issuer extract (Let’s Encrypt: 116,262,883 observations). Items explicitly labelled industry knowledge — Let’s Encrypt’s March 2018 wildcard launch, historical wildcard pricing, the NSA’s 2021 scoping guidance — are public record, not census measurements.
- No causal claims. We measure deployment; we do not observe why any given operator chose a wildcard, and we do not name or grade any individual domain.
- Aggregate only. Data is stored and processed within the EU.
FAQ
What percentage of websites use wildcard certificates? In our August 2026 census, 28.5% of domains that presented a TLS certificate presented a wildcard — 66,011,927 of 231,455,163 observations. Measured against all 376.9 million graded domains, wildcard certificates front 17.5% of the measured web.
Are wildcard certificates less secure than regular certificates? The cryptography is identical; the risk model is not. A wildcard’s single private key is valid for every first-level subdomain and typically gets deployed to more machines, so one leak exposes the whole namespace level instead of one service — including subdomains that were never created, which makes stolen wildcards useful for convincing phishing hosts. Scoped certificates confine a compromise to the host on the certificate.
Why do so many sites use wildcard certificates? Price and platforms. Free wildcard issuance (Let’s Encrypt has offered it since March 2018, via DNS-01 validation) removed the cost barrier, and hosting providers, CDNs and SaaS platforms deploy wildcards at scale on customers’ behalf because one certificate per tenant namespace is operationally simpler. Let’s Encrypt alone accounts for 50.2% of certificate observations in our census.
Should I replace my wildcard certificate with named certificates? If your subdomains run on separate infrastructure, scoping certificates per hostname meaningfully shrinks the blast radius of a key compromise, and ACME automation makes the extra certificates free to operate. If everything terminates on one machine anyway, the gain is smaller. Either way, keep the private key on as few systems as possible and publish a CAA record to restrict who can issue for your domain.
Does a wildcard certificate cover all levels of subdomains?
No. *.example.com matches exactly one label: shop.example.com but not a.b.example.com and not the bare example.com (which is why wildcards commonly carry the apex as an additional name). Covering deeper levels needs additional wildcard entries — each one another scope riding on the same key.
What should I do if my organisation uses wildcard certificates? Start with an inventory: which wildcard certificates do you hold, how many servers carry copies of each private key, and which of those servers are the least-hardened? If you find your wildcard key on a staging server, a CDN origin, and a developer’s laptop, you have already extended the blast radius well beyond what your architecture requires. Publish a CAA record for your domain to restrict which CAs can issue against your name. If your subdomains run genuinely separate services on separate infrastructure, migrate each service to its own named certificate — ACME automation makes this effectively free to operate. Treat the wildcard key itself with the same rigour you would apply to a root credential.
How does this compare to the previous census (July 2026)? The August 2026 census establishes the baseline measurement at this scale under methodology v9, having expanded the scanned population to 432 million domains. The July 2026 round preceded the current methodology and scope. Direct percentage comparison is in preparation. What we can observe directionally is that the structural forces driving wildcard adoption — free issuance from Let’s Encrypt since 2018, platform-level deployment by hosting providers — have had years to compound. The 28.5% figure reflects the accumulated result of those forces across the largest domain sweep this census has conducted.
Why does this matter for security and IT teams? A wildcard certificate is a key-management decision disguised as a convenience decision, and most teams that inherited one have never explicitly reviewed the trade. The question your security team should be able to answer about every wildcard in your inventory is: how many machines hold a copy of this key, and what is the weakest one? If the answer is “we don’t know”, that is the actual risk — not the certificate type itself. The census data showing 66 million domains on wildcard certificates suggests that most of those decisions were made by platforms on the domain owner’s behalf, not by anyone who weighed the shared-fate model explicitly.
What this means
IT managers and security teams who discover a wildcard certificate in their environment should immediately ask two questions: how many systems hold copies of the private key, and how would you know if one of them was compromised? Wildcard key material that lives on a web server, a staging environment, a CDN origin, and a network appliance is only as secure as the weakest of those four hosts. Most incident response teams discover the answer to this question after a breach, not before. Conducting that audit proactively — identifying every wildcard, every system carrying its key, and every person who has ever had access to the key file — is the concrete step that moves wildcard risk from theoretical to managed.
For business owners and non-technical decision-makers, the practical concern is subtler but equally real. A wildcard certificate means that a single credential, if leaked, could be used to impersonate your login page, your API, your customer portal, or a subdomain that doesn’t exist yet — and browsers will show a green padlock on all of them. Phishing attacks that abuse stolen wildcard certificates are indistinguishable from your real site at the TLS layer. If your organisation handles customer data, payment information, or credentials, asking your IT provider whether your certificate is a wildcard and how the key is protected is a reasonable governance question, not a technical one.
The longer-term remediation path — migrating from wildcards to per-hostname certificates — costs nothing in most modern hosting environments because ACME automation handles the operational overhead. The barrier is almost always inertia: the wildcard was set up years ago, it renews automatically, and nobody has revisited the decision. The census data suggests that more than 66 million deployments are in exactly that state. The first step is knowing whether yours is one of them.
Data to cite
“28.5% of TLS certificate observations in the August 2026 census were wildcard certificates — 66,011,927 of 231,455,163 domains measured on the public web.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“17.5% of all 376.9 million graded domains in the defaults.exposed August 2026 census present a wildcard certificate at their web front door — nearly one in six of the measured internet.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“A single wildcard certificate covers every first-level subdomain of its name, including subdomains that do not yet exist — giving anyone who holds the private key the ability to impersonate arbitrary hostnames under the domain.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“Let’s Encrypt, the census’s largest certificate issuer at 116.3 million observations — 50.2% of all domains presenting a certificate — has issued free wildcard certificates since March 2018, removing the cost barrier that once limited wildcard adoption.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“More than two in three domains on the TLS web — 71.5%, or 146,013,938 observations — still scope their certificates to named hosts rather than wildcards, meaning the tighter practice remains the majority position.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“The wildcard model — one private key covering an entire subdomain namespace — has spread to more than a quarter of the TLS web, mostly through platform defaults and price collapse rather than deliberate security architecture decisions.” — defaults.exposed August 2026 Domain Security Census (432M domains)
Related reading
- The State of Domain Security 2026 → — the flagship census report this edition draws from.
- The Internet Security Grade Curve → — how 376 million graded domains distribute from A to F.
- The Fully Protected Few → — how rare it is for a domain to pass every check at once.
See where your own domain stands
A wildcard certificate is one line in a much bigger picture. Our census grades real, live domains across 34 externally observable security checks, and most of what a failing domain is missing is free and quick to fix — the barrier is almost never cost, it’s that nobody told the owner it mattered. You can check your domain privately and free, and see exactly which checks you pass.
Check your domain free at defaults.exposed — see exactly how your domain scores on certificate type, key scope, and TLS configuration. Takes 30 seconds. No account needed. Read the flagship census report: The State of Domain Security 2026 →
Aggregate data only. Data stored and processed in the EU.
How to cite this report
Press / blog: defaults.exposed (2026). Wildcard Certificates: 28.5% of the TLS Web on One Key. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/en/articles/wildcard-certificate-report
Academic: defaults.exposed. (2026, August 18). Wildcard Certificates: 28.5% of the TLS Web on One Key. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/en/articles/wildcard-certificate-report
In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=231,455,163 certificates)
About the defaults.exposed August 2026 Census
The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded 376,928,781 of them using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.
Methodology: defaults.exposed/en/articles/domain-security-scoring-methodology-v9 Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026