A wildcard certificate is the only kind of TLS certificate where issuing it once means the same private key ends up on machines you’ve forgotten you own.
That’s the whole problem in one sentence, but nobody feels it until the day a low-value box gets popped. Some staging server, some marketing microsite, some internal dashboard that a contractor stood up in 2023 and nobody decommissioned. The attacker doesn’t care about the box. They care about the file sitting on it: STAR_example_com.key. The same key that’s on production. The same key that proves you are *.example.com to every browser on earth.
Now they can be payments.example.com. They can be login.example.com. They can be any name under your domain they feel like inventing, with a certificate that validates perfectly, because it’s your certificate. You handed every server in your fleet a master key and then you let the weakest one hold a copy.
The convenience is real, which is why people keep doing it
I want to be fair to wildcards, because the appeal isn’t stupid. You get *.example.com, you stop filing a ticket every time someone spins up a new subdomain, and you stop waiting on issuance for whatever-the-intern-named-it.example.com. One cert, infinite subdomains, no renewal dance per name. In a world where you’re managing this by hand, that’s a genuine reduction in toil.
But “in a world where you’re managing this by hand” is doing all the work in that sentence. We don’t live there anymore. ACME and Let’s Encrypt made per-name certificates free and automatic in 2015. The thing wildcards save you — the manual labor of getting a certificate for each name — is the exact thing that got automated out of existence. You’re optimizing away a cost that a cron job already pays for you, and you’re paying for that optimization in key-distribution risk.
A wildcard key has to travel, and that’s the antipattern
Here’s the part people gloss over. A certificate’s security lives entirely in its private key. The cert itself is public — it’s literally published to Certificate Transparency logs the moment it’s issued. The only secret is the key. So the entire security question for any certificate is: how many places does the private key exist, and how well is each of them guarded?
A per-host certificate answers that question well. api.example.com has a key that lives on the API servers and nowhere else. If those get breached you have a bad day, but the cert for payments.example.com is a different key on different hardware and it’s untouched.
A wildcard answers it badly by design. To serve *.example.com from twelve different services, the key has to be on those twelve services — or in a load balancer, a CDN edge config, a Kubernetes secret replicated across a cluster, a developer’s laptop where someone tested it once and forgot. Every copy is a place it can leak. You took the thing whose entire job is to stay in one well-guarded place and you mandated that it be in many places, some of which you can’t even enumerate. The convenience and the risk are the same mechanism: one key, everywhere.
You can’t revoke half of it
The failure mode gets worse when you try to clean up. Say you confirm the staging box leaked the key. With per-host certs, you revoke and reissue the one cert for the one compromised name and the rest of your infrastructure never notices.
With a wildcard, there is no “the one cert.” There’s one certificate covering everything, and revoking it revokes it for everything — every subdomain, every service, all at once. So you’re choosing between leaving a known-compromised key live in production, or triggering a coordinated reissue-and-redeploy across every system that uses the wildcard, simultaneously, under incident pressure. Revocation was supposed to be your safety valve. With a wildcard it’s a detonator.
The matching rules don’t even do what you think
People also reach for wildcards assuming they cover more than they do. *.example.com matches exactly one label level. It covers foo.example.com. It does not cover bar.foo.example.com, and it does not cover the bare example.com itself. RFC 9525 — the 2025 standard for service identity in TLS that replaced the long-serving RFC 6125 — spells this out: the wildcard is only legal as the complete leftmost label, and a client matching *.example.com should compare nothing but that single leftmost label.
So the apex of your domain, the name people actually type into the address bar, needs its own certificate anyway. And any second-level subdomain — the eu.api.example.com, staging.app.example.com shape that real infrastructure grows into — falls straight through. The wildcard you bought for coverage covers the imaginary names and misses the real ones, and people “fix” this by buying a wildcard at each level, which means more keys in more places, which is the original problem with extra steps.
That same RFC, by the way, notes that putting one certificate in front of multiple services on a host is itself discouraged, because it opens the door to cross-protocol attacks — and a wildcard is the maximal version of “one certificate, many services.” The standards body spent a revision cycle making the guidance sharper, and the direction it sharpened toward was: narrow your certificates, don’t widen them.
The thing wildcards take from you that you don’t notice
There’s a quieter cost. Certificate Transparency means every per-name certificate you issue lands in a public, append-only log. That sounds like a privacy leak — now everyone can see you have an internal-admin.example.com — and it is one. But it’s also a free, continuous inventory of every TLS name in your estate. Security teams monitor CT logs to catch certificates they didn’t authorize: a sign of a compromised account, a rogue deployment, a subdomain takeover in progress.
A wildcard erases that signal. *.example.com appears in the logs exactly once and tells a watcher nothing about which names are actually live behind it. You’ve traded a slightly smaller public footprint for total blindness in your own monitoring. An attacker who gets the wildcard key can stand up secure-login.example.com and serve a flawless certificate for it, and your CT monitoring — the system whose entire purpose is to flag exactly this — sees nothing, because the wildcard already covered the name before the name existed.
What to do instead
Issue a certificate per name and automate it. That’s the entire recommendation, and ACME makes it a solved problem: a client requests, validates, installs, and renews each certificate without a human in the loop. The keys stay on the hosts that need them. A breach stays scoped to what was breached. Revocation stays surgical. CT logs stay useful as an inventory.
If you have a genuinely dynamic subdomain space — thousands of customer names, generated on the fly, where pre-issuing per name isn’t workable — then yes, a wildcard might be the pragmatic answer, and ACME will even issue it for you (though only via the DNS-01 challenge, since proving control of *.example.com means proving control of the zone, not of one web root — which quietly hands a new high-value secret, your DNS API credentials, to your automation). That’s a real use case. It is also a much narrower one than the number of wildcards in production suggests.
The rest of the time, a wildcard is a convenience from a decade we already left, secured by a key you’ve copied to places you can’t list, that you can’t revoke without an outage, that hides the one signal that would warn you it leaked. Convenient, sure. So is leaving the master key under the doormat.