What Is a Wildcard Certificate? Uses, Risks and When to Avoid

Published 2026-08-21

A wildcard certificate is a single TLS certificate whose name field contains a wildcard character — *.example.com — so it validates every first-level subdomain of a domain at once: www.example.com, mail.example.com, api.example.com, and any other host you invent later, all from one certificate and one private key. That last detail is the whole story. In the defaults.exposed August 2026 census, which evaluated TLS across 231,991,983 HTTPS-serving domains, 28.5% of them — roughly 66 million domains — rely on a wildcard certificate. Wildcards trade a real operational win, one certificate instead of dozens, for a real security cost: because every subdomain shares the same key, one compromised private key exposes all of them simultaneously. This guide explains what a wildcard is, how it differs from SAN and single-domain certificates, why teams reach for it, the blast radius it creates, and when to avoid one.

If you have ever run a website with more than a handful of subdomains, someone on your team has proposed a wildcard certificate, and the proposal was reasonable. Wildcards are cheap, fast to deploy, and they make “spin up a new subdomain” a five-minute job instead of a certificate-request ticket. The question is never whether they are convenient — they plainly are — but whether the convenience is worth putting every subdomain’s security on a single key. The figures throughout come from the defaults.exposed August 2026 census, an independent scan of 432,127,908 domains graded as of 2026-08-16.

What a wildcard certificate is

Every TLS certificate carries a set of names it is valid for. A browser connecting to shop.example.com checks that the certificate the server presents actually lists shop.example.com among its names; if it does not, the connection fails with a name-mismatch error. Normally each name is spelled out in full.

A wildcard certificate replaces the left-most label of a hostname with an asterisk. A certificate issued for *.example.com matches any single label in that position: www.example.com, blog.example.com, vpn.example.com, and a subdomain you have not created yet all satisfy it. The certificate authority validates that you control example.com, and in return you get a certificate that covers the entire first level of subdomains beneath it.

Two rules constrain the wildcard, and both matter:

A wildcard covers exactly one label. *.example.com matches api.example.com but not api.eu.example.com — that is two labels deep. It also does not match the bare example.com (the apex). To cover both the apex and its subdomains, a certificate has to list example.com and *.example.com as two separate names.
The wildcard must be the left-most label. www.*.example.com and *.*.example.com are not valid wildcard forms that public CAs will issue. The asterisk sits at the front, standing in for one subdomain level, and nowhere else.

Under the hood, the wildcard name lives in the certificate’s Subject Alternative Name (SAN) extension, the same field that holds ordinary names — which is exactly why the line between “wildcard certificate” and “SAN certificate” is blurrier than most people assume. That distinction is worth pinning down, because it is the source of most confusion when teams choose between certificate types.

Wildcard vs SAN vs single-domain certificates

There are three shapes a certificate’s name coverage can take, and the choice between them is the practical decision most teams actually face.

Single-domain (single-name) certificate. Covers exactly one hostname: www.example.com and nothing else. Every additional host — mail, shop, api — needs its own certificate, its own issuance, its own renewal, its own private key. This is the most granular option and the most administrative work. Its security advantage is isolation: a key stolen from the shop host protects only shop.

SAN (multi-domain) certificate. Lists several explicit names in the SAN field of one certificate — for example example.com, www.example.com, shop.example.com, and api.example.com on a single cert. SAN certificates can even span different registrable domains (example.com and example.net together). The coverage is exactly the names you list — no more, no less — so a new subdomain means reissuing the certificate to add its name. One certificate, one key, but an explicit, auditable list of what it covers.

Wildcard certificate. Covers *.example.com — every first-level subdomain, including ones that do not exist yet, without reissuing. This is the least administrative work and the broadest coverage from a single key. It is also the only one of the three whose coverage is open-ended: you cannot enumerate, from the certificate alone, exactly which hosts are using it.

The key security difference is not the certificate format — a wildcard name is technically just one more SAN entry — but the coverage model. A SAN certificate says “these named hosts, and I can tell you which.” A wildcard says “anything one level down, named or not.” When you are reasoning about blast radius, that open-ended coverage is the property that matters, and it is why “wildcard vs SAN” is a genuine security decision and not just a purchasing one.

For the machinery underneath all three — how a browser decides to trust any of them in the first place — see What Is a Certificate Authority? How Web Trust Works. If you are still untangling the terms themselves, SSL vs TLS: What’s the Difference and Which Do You Have? draws the line between the protocol and the certificate. The grading logic defaults.exposed applies to certificate validity is documented in the certificate validity methodology.

Why teams love wildcards: cost and convenience

Wildcards did not reach 28.5% of the TLS web by accident. They solve genuine operational pain, and it is worth being honest about the upside before weighing the risk.

One purchase, unlimited subdomains. A commercial wildcard costs more than a single-name certificate but far less than buying a separate certificate for every subdomain. For an organisation running dozens of internal and external hosts, the arithmetic is decisive: one certificate line item instead of forty.

Zero-friction expansion. The property developers love most is that a wildcard covers subdomains that do not exist yet. Marketing spins up launch.example.com for a campaign; the platform team stands up staging-7.example.com for a test; neither needs to touch the certificate authority. The certificate already covers them. In fast-moving environments this removes a recurring bottleneck.

Simpler load balancers and proxies. Terminating TLS at a single reverse proxy or load balancer is cleaner with one wildcard certificate than with a sprawling SAN list that has to be reissued every time a host is added. Configuration stays static while the estate grows.

Fewer renewal events to track. One certificate means one expiry date to monitor instead of many. That matters, because expiry is one of the most common ways TLS silently breaks — the census counts 5.2 million domains serving certificates that have already expired, quantified in Expired SSL Certificates: 5.2 Million Sites Still Serving. A single renewal is easier to automate reliably than forty.

None of these benefits is imaginary. The mistake is treating them as free. Every one of them flows from the same underlying fact — one certificate, one key, covering everything — and that fact is also the source of the risk.

The hidden risk: one key, every subdomain

A certificate is only half of a TLS deployment. The other half is the private key that pairs with it, and the private key is the asset an attacker actually wants. Whoever holds the private key can impersonate every name the certificate covers. For a single-name certificate that is one host. For a wildcard, it is every subdomain of your domain, forever — until the certificate is revoked and reissued with a new key.

This is the blast-radius problem, and it plays out in several concrete ways.

Wide sharing multiplies exposure. The operational appeal of a wildcard — put it on every server — is also its weakness. To serve *.example.com from your reverse proxy, your API gateway, your mail host, and a third-party CDN, the same private key has to be installed on, or trusted by, all of them. The key is now only as safe as the least-secure machine or vendor that holds it. A single-name certificate on the API host, by contrast, keeps the API’s key on the API’s server and nowhere else.

One theft compromises everything at once. If any host holding the wildcard key is breached, the attacker does not gain the ability to impersonate that one host. They gain the ability to impersonate login.example.com, payments.example.com, admin.example.com, and every other subdomain — including ones the attacker had no direct access to — because all of them present the same key. A compromise that would have been contained to one service becomes a compromise of the whole namespace.

Revocation is all-or-nothing. When a wildcard key is exposed, you cannot revoke it for the breached host alone. Revoking the certificate invalidates it everywhere, so every subdomain must be re-keyed and redeployed at the same time — often under incident pressure, across systems owned by different teams. What should be a scoped cleanup becomes a domain-wide fire drill.

Handing a wildcard to a third party hands them your namespace. Giving a vendor, CDN, or contractor a wildcard key to terminate TLS on your behalf gives them a credential valid for every subdomain you have. If their systems are breached, or their access is never properly revoked when the relationship ends, the exposure is your entire first-level namespace, not the one hostname they were engaged to run.

To make the difference concrete, picture two organisations with identical estates: an apex site, a customer login, a payments endpoint, an internal admin panel, and forty marketing hosts. The first secures everything with one *.example.com wildcard installed across every server. The second uses automated single-name certificates for login, payments, and admin, and a wildcard only for the forty marketing hosts. Now a low-privilege marketing box is breached in both organisations. In the first, the attacker lifts the wildcard key and can immediately stand up a convincing login.example.com and payments.example.com to harvest credentials and reroute money — the compromise of a brochure server became the compromise of the payment flow. In the second, the same breach yields only the marketing wildcard; login and payments present different keys the attacker never touched, and the incident stays contained to where it started. Same technical event, radically different blast radius, decided entirely by how the keys were scoped.

The risk is not that wildcards are cryptographically weaker — the encryption is identical. It is that they concentrate trust. A wildcard turns “how well is this one host protected” into “how well is the least-protected host that holds this key protected,” and the answer to the second question is almost always worse. Wildcards also do nothing for the rest of your certificate hygiene: the same census that finds 28.5% wildcard adoption finds 3.3 million domains serving self-signed certificates that no browser trusts — the subject of Self-Signed Certificates: The 3.3 Million Domain Census — and 5.2 million serving expired ones. Convenience at the coverage layer does not fix problems at the trust or lifecycle layer.

How common are wildcards? (census data)

To measure adoption, the defaults.exposed August 2026 census scanned 432,127,908 domains and evaluated the TLS configuration of the 231,991,983 that serve HTTPS. Across that TLS-evaluable population, 28.5% present a wildcard certificate — roughly 66 million domains where a single private key covers an entire first level of subdomains.

That is close to three in every ten HTTPS-serving domains, which puts wildcards well past niche and into mainstream infrastructure. The adoption is driven partly by the platforms most domains sit behind: managed hosting, CDNs, and reverse proxies frequently default to a wildcard covering their tenants, so a domain owner can be relying on a wildcard without ever having chosen one. That is the practical reason to check rather than assume — many operators do not know their certificate is a wildcard until they look.

The figure sits alongside the census’s other certificate findings, and the cluster tells a consistent story about certificate hygiene at internet scale:

28.5% of TLS-serving domains use a wildcard — broad coverage from a single key.
3.3 million domains serve self-signed certificates a browser will reject outright.
5.2 million domains serve certificates that have already expired.

Read together, these numbers say that the certificate layer is where convenience routinely wins over caution. A wildcard is the convenient choice; a self-signed or expired certificate is convenience gone wrong in the other direction. Our twin analysis of the wildcard figure, Wildcard Certificates: 28.5% of the TLS Web on One Key, breaks the adoption pattern down by the platforms and provider defaults driving it. For how defaults.exposed grades the signature and key strength that sit behind any certificate, wildcard or not, see the certificate signature algorithm and certificate key strength methodology.

When to use a wildcard and when to avoid one

Wildcards are not a mistake to be eliminated — they are a tool with a specific fit. The decision comes down to how much you can contain the shared key.

A wildcard is a reasonable choice when:

The subdomains it covers are low-sensitivity and operationally similar — a swarm of marketing landing pages, documentation sites, or short-lived campaign hosts that share a threat profile and hold nothing an attacker would escalate through.
You genuinely need coverage for subdomains that do not exist yet, and issuing per-host certificates would create a real bottleneck.
The key can be tightly held — terminated at one controlled proxy or load balancer, stored in a hardware security module or secrets manager, and never copied onto general-purpose or third-party machines.
You have automation to re-key and redeploy quickly, so that if the key is ever exposed, rotating it across every host is a routine job rather than a crisis.

Avoid a wildcard — prefer single-name or SAN certificates — when:

The domain includes high-value hosts: login, payments, admin, sso, vpn, anything holding credentials or money. These deserve isolated keys so a breach elsewhere cannot impersonate them. Automated issuance (ACME / Let’s Encrypt) has made per-host certificates nearly free to run, which removes the historical excuse for putting a payment gateway on the same key as a blog.
You would have to spread the key across many machines or hand it to third parties to make the wildcard useful. Wide distribution is precisely the condition under which the blast radius is worst.
You want an auditable inventory of exactly which hosts hold which certificate. A SAN certificate’s explicit name list gives you that; a wildcard’s open-ended coverage does not.
You are subject to compliance or cyber-insurance controls that ask you to demonstrate key isolation and scoped blast radius. “One key covers our entire namespace” is a difficult sentence to defend to an underwriter or auditor.

A common and sensible middle path is a hybrid: a wildcard for the long tail of low-risk, high-churn subdomains, and dedicated single-name certificates — issued and renewed automatically — for the handful of hosts whose compromise would actually hurt. That keeps the convenience where it is cheap and the isolation where it counts. Whichever way you go, the certificate’s underlying strength still matters: check that it uses a modern signature and a strong key (certificate key strength) and that TLS itself is configured with current protocol versions (TLS version methodology).

Check whether your domain relies on a wildcard

The first problem for most teams is not deciding whether a wildcard is appropriate — it is discovering they already have one. Because managed platforms and CDNs so often default to wildcards, a domain can be covered by one that no one on the current team chose. Before you can reason about blast radius, you have to know the certificate is there.

Check your domain free at defaults.exposed — it reads your live certificate straight from the TLS handshake and tells you what type it is, whether it is valid and current, what signature and key strength it uses, and where your HTTPS configuration falls short. It takes about 30 seconds and needs no account. If the scan flags a wildcard, that is not automatically a failure — it is a prompt to ask the two questions that decide whether the wildcard is safe: how widely is this key shared, and what would it cost to impersonate every subdomain if it leaked.

What this means

For developers and infrastructure teams, a wildcard is a convenience you should choose deliberately, not inherit by default. Treat the private key as the crown jewel it is: terminate it in one place, keep it out of third-party hands, and have the automation to rotate it fast. Reserve isolated single-name certificates for login, payments, admin, and anything else whose compromise would let an attacker escalate. With ACME automation, per-host certificates cost almost nothing to operate — the old trade-off that justified putting everything on one wildcard key has largely dissolved.

For security and compliance owners, the wildcard question is a blast-radius question, and blast radius is exactly what underwriters and auditors are learning to ask about. A single key valid for every subdomain is a concentration of trust that is hard to defend in a control review and expensive to contain in an incident. Inventory where your wildcards are, know which hosts hold each key, and be able to show that your highest-value services do not share a certificate with your lowest-value ones. The 28.5% adoption rate across the TLS web means this is not a rare edge case — it is the default posture of nearly a third of the encrypted internet, and most owners have never checked which side of the line they are on.

FAQ

What is a wildcard certificate? A wildcard certificate is a TLS/SSL certificate whose name field contains a wildcard character — written *.example.com — so it validates every first-level subdomain of a domain from a single certificate and a single private key. It matches www.example.com, mail.example.com, and any subdomain you create later, but not the bare apex example.com or deeper names like a.b.example.com. In the defaults.exposed August 2026 census, 28.5% of the 231,991,983 TLS-serving domains use one. The appeal is one certificate for unlimited subdomains; the cost is that the shared key covers all of them at once.

Are wildcard certificates safe? The encryption is identical to any other certificate — a wildcard is not cryptographically weaker. The risk is concentration: because every subdomain shares one private key, that key must often be installed on many servers, and a breach of any one of them lets an attacker impersonate every subdomain simultaneously. Revocation is also all-or-nothing, forcing a domain-wide re-key under pressure. A wildcard is safe when the key is tightly held in one controlled place and covers only low-sensitivity hosts; it is risky when the key is spread across many machines or handed to third parties. You can check whether your domain relies on one, free, at defaults.exposed.

When should you use a wildcard certificate? Use a wildcard when you need to cover many low-sensitivity, operationally similar subdomains — landing pages, docs sites, short-lived campaign hosts — or subdomains that do not exist yet, and when you can keep the private key isolated at a single controlled termination point. Avoid it for high-value hosts such as login, payments, admin, or sso, which deserve dedicated single-name certificates so that a breach elsewhere cannot impersonate them. A hybrid is often best: a wildcard for the low-risk long tail, isolated automated certificates for the hosts whose compromise would actually cause harm.

What is the difference between a wildcard and SAN certificate? A SAN (multi-domain) certificate lists several explicit hostnames in its Subject Alternative Name field — for example example.com, www.example.com, and api.example.com — and covers exactly those names, no more. A wildcard covers *.example.com: every first-level subdomain, including ones that do not exist yet. Technically a wildcard is just one more SAN entry, so the real difference is the coverage model: a SAN certificate gives you an explicit, auditable list of covered hosts, while a wildcard gives open-ended coverage you cannot enumerate from the certificate alone. For blast radius and auditability, that explicit list is the SAN certificate’s advantage; for zero-friction expansion, the open coverage is the wildcard’s.

Data to cite

“28.5% of TLS-serving domains use a wildcard certificate, covering every first-level subdomain from a single private key.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“A single wildcard certificate covers unlimited subdomains, so one compromised private key exposes all of them simultaneously.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“defaults.exposed evaluated TLS configuration across 231,991,983 HTTPS-serving domains for the August 2026 census.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“3.3 million domains serve self-signed certificates and 5.2 million serve expired ones — wildcard convenience does not fix basic certificate hygiene.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“432,127,908 domains were scanned in the defaults.exposed August 2026 census.” — defaults.exposed August 2026 Domain Security Census (432M domains)

See where your own domain stands

A wildcard certificate is neither good nor bad in the abstract — it is a concentration of trust that is right for some hosts and wrong for others. The problem is that most teams do not know which certificate type they are actually serving, because the platform underneath chose it for them. You cannot manage a blast radius you have not measured.

Check your domain free at defaults.exposed — it reads your live certificate from the TLS handshake and tells you its type, validity, signature algorithm, and key strength, and flags where your HTTPS setup falls short. Takes 30 seconds. No account needed. If you want the certificate and TLS gaps closed properly — right certificate type per host, current validity, strong keys, modern protocol versions — see how the fix works.

Read the flagship census report: The State of Domain Security 2026 →

Aggregate data only. Data stored and processed in the EU.

Data source: defaults.exposed August 2026 census, methodology v9, as of 2026-08-16. 432,127,908 domains scanned; TLS evaluated across 231,991,983 HTTPS-serving domains. All figures are counts or shares of graded domains. References: RFC 6125 (name matching), RFC 5280 (X.509), RFC 8446 (TLS 1.3).

How to cite this report

Press / blog: defaults.exposed (2026). What Is a Wildcard Certificate? Uses, Risks and When to Avoid. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/v9/articles/what-is-a-wildcard-certificate-uses-risks-and-when-to-avoid

Academic: defaults.exposed. (2026, August 21). What Is a Wildcard Certificate? Uses, Risks and When to Avoid. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/v9/articles/what-is-a-wildcard-certificate-uses-risks-and-when-to-avoid

In-line citation: (defaults.exposed, August 2026 Domain Security Census, TLS evaluated across n=231,991,983 HTTPS-serving domains)

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 them using methodology v9, evaluating TLS configuration across the 231,991,983 domains that serve HTTPS. 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/v9/methodology Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026

Data sourced from the August 2026 grading methodology (v9) — 34 checks, 376 million domains. Browse the census statistics or the Census Explorer, or see all August 2026 research →