Abstract
In October 2021 the NSA published an advisory titled “Avoid Dangers of Wildcard TLS Certificates.” It reiterated what security consultants had been saying for years: don’t use wildcard certificates. Single-name certificates per host are safer.
Five years later, we counted the certificates that are actually used. One in three domains has a wildcard on it. For .bank domains, where you need a security review just to register, it’s four in five.
Operators aren’t careless. The advice wasn’t followed because it asked for 10x the certificates, 10x the work, and 10x the outage risk with no advice on how to manage them.
What the CT logs say
Every publicly trusted TLS certificate is published to Certificate Transparency logs. We run a copy of them for CertKit’s CT log tool, and so we can ask interesting questions about real certificate use.
Headline. 338.4 million registrable domains have at least one active certificate. 130.2 million of them, 38.5%, have wildcards.
Method. We took every finalized certificate with a notAfter date in the future as of September 18, 2026, and grouped by registrable domain (the public suffix list’s eTLD+1, so shop.example.co.uk and www.example.co.uk are considered one domain). A domain counts as a wildcard domain if any of its active certificates has a *. entry in its subject alternative names. Counts are per domain, not per certificate.
Our scanner has fully ingested every log shard that can hold a certificate valid on that date, so the count is complete rather than a sample. The full tables are in one CSV, free to reuse with attribution (CC BY 4.0).
Two TLDs are public suffix list artifacts and are excluded from the headline, see the caveats below. Without them it’s 35.3%. Either way, more than a third.
By certificate lifetime
Lifetime is the best proxy for automation in this data. As lifetime shrinks, manual processes are less and less likely. Nobody renews a 6-day certificate by hand.
| Certificate lifetime | Domains | With a wildcard | Share |
|---|---|---|---|
| < 7 days | 39,977 | 14,145 | 35.4% |
| 7 - 47 days | 216,471 | 15,857 | 7.3% |
| 48 - 90 days | 266,605,487 | 123,699,053 | 46.4% |
| 91 - 200 days | 75,053,026 | 4,109,115 | 5.5% |
| > 200 days | 20,242,764 | 3,905,688 | 19.3% |
The 90-day bucket is free, modern ACME. The 91 to 200 day bucket is commercial issuance since the March 2026 lifetime cap, and it’s almost wildcard-free. Commercial CAs charge extra for wildcards, and a lot of those certificates cover a single parked or hosted page. The “> 200 day” bucket is the last of the 1-year certificates from before March 2026. That’s what IT chose when a wildcard was an extra cost, but operationally simpler. 1 in 5 thought it was the right choice.
The 6-day row is really surprising here. Those 40,000 domains run certificates that expire within the week, so DNS validation and deployment are fully automated with nobody in the loop. Over a third of 6-day cert domains use wildcards.
By certificate authority
| Issuer | Domains | With a wildcard | Share |
|---|---|---|---|
| Let’s Encrypt | 221,957,210 | 93,637,685 | 42.2% |
| Google Trust Services | 93,536,228 | 75,025,861 | 80.2% |
| GoDaddy | 79,465,819 | 165,565 | 0.2% |
| SSL.com | 22,235,435 | 21,740,080 | 97.8% |
| Sectigo | 21,187,333 | 15,942,223 | 75.2% |
| ZeroSSL | 6,389,758 | 1,027,911 | 16.1% |
| DigiCert | 5,530,265 | 241,923 | 4.4% |
| Amazon | 4,200,346 | 2,448,589 | 58.3% |
| Actalis | 1,255,117 | 1,241,096 | 98.9% |
| GlobalSign | 861,153 | 170,209 | 19.8% |
The split is between CAs that issue wildcards for free through ACME and CAs that sell them. The free ones, like Let’s Encrypt and Google, issue a lot of wildcards. Most paid ones barely issue any.
Google Trust Services and SSL.com are two of the three CAs behind Cloudflare’s Universal SSL, which issues example.com plus *.example.com for every zone by default. (Let’s Encrypt is the third.) We can’t separate Cloudflare’s certificates from anyone else’s in this data, but those two columns are a fair proxy for its footprint, somewhere between 75 and 97 million wildcard domains depending on how much they overlap. Take all of that out and the rest of the internet still runs wildcards on 14% to 21% of domains. The “> 200 day” bucket above, which Cloudflare never touched, is at 19%. Two datasets pointing at the same conclusion.
By top-level domain
| TLD | Domains | With a wildcard | Share |
|---|---|---|---|
| .com | 138,132,527 | 43,539,453 | 31.5% |
| .net | 11,259,043 | 2,765,856 | 24.6% |
| .org | 10,343,051 | 3,094,007 | 29.9% |
| .de | 9,744,535 | 2,898,433 | 29.7% |
| .uk | 7,069,087 | 2,348,262 | 33.2% |
| .cn | 4,240,878 | 2,343,906 | 55.3% |
| .br | 3,682,475 | 1,734,080 | 47.1% |
| .ru | 3,417,720 | 767,238 | 22.4% |
| .fr | 2,951,862 | 715,805 | 24.2% |
| .io | 1,302,188 | 474,643 | 36.4% |
| .jp | 1,174,836 | 146,808 | 12.5% |
Countries with strong local hosting markets run low. Japan, Switzerland, France, and Russia are all under 25%, because hosting control panels issue a Let’s Encrypt certificate per site. Cheap bulk-registration TLDs run high (.sbs, .cfd, .lol, .buzz, and .icu are all above 78%), which says more about who sits behind a free CDN than about anyone’s security posture.
Then there are the TLDs that the NSA was specifically trying to advise.
| TLD | Domains | With a wildcard | Share |
|---|---|---|---|
| .gov | 14,790 | 7,840 | 53.0% |
| .edu | 6,524 | 4,643 | 71.2% |
| .mil | 308 | 120 | 39.0% |
| .bank | 2,043 | 1,609 | 78.8% |
| .insurance | 117 | 59 | 50.4% |
| .pharmacy | 867 | 738 | 85.1% |
These populations are small, but the direction is consistent. US government, higher education, banking, and pharmacy all run wildcards at a higher rate than everyone else. Registering a .bank domain requires passing fTLD’s security requirements, and 79% of them have a wildcard certificate.
Caveats
The CA and lifetime tables are not additive. A domain with certificates from two CAs, or with a 90-day and a 200-day certificate at the same time, shows up in both rows.
Two top-level domains are artifacts of the public suffix list, not registrations. .dev shows 26 million “domains” at 99% wildcard because pages.dev and workers.dev are public suffixes, so every Cloudflare Pages project counts as its own registrable domain, and Cloudflare gets wildcards for everything. .ph shows 16.8 million domains at 0.6% wildcard for the same reason, under a private suffix we couldn’t identify. With both included the headline is 38.5%. Without them it’s 35.3%.
We have one snapshot, so this says nothing about whether wildcard use is going up or down. We counted domains with at least one wildcard, not domains that use only wildcards, so we can’t say how many organizations have gone all-in. And the numbers are per domain, not per certificate. A domain with one wildcard and 40 single-host certificates counts the same as a domain with one wildcard and nothing else.
What’s the security risk of a wildcard certificate?
The NSA advisory is the most official version of advice that nearly every security consultant repeats: wildcards are bad because of private key exposure. A wildcard’s private key has to be on every server that terminates TLS for any covered subdomain. More copies in more places means more chances for one to leak. And when it leaks, the damage isn’t one site. The attacker can present a valid certificate for any subdomain, including ones that don’t exist yet. payroll.example.com doesn’t have to be a real system for a phishing page at that name to show a padlock. The wildcard raises both the risk of a key compromise and the impact of one.
While that’s correct, it’s also hard to pull off. A stolen private key can’t decrypt recorded traffic thanks to perfect forward secrecy, so its only use is impersonating your server, and that needs a network position between the victim and you. We looked at how often that happens. It’s either the coffee shop Wi-Fi of one specific victim or the Mossad, and the Mossad will hijack your DNS and get a fresh certificate instead of bothering with your key.
What about ALPACA? The advisory also names ALPACA, a 2021 attack where a wildcard certificate on a sloppy service can be used to vouch for a careful one. An attacker in the network path redirects a browser’s connection for www.example.com to ftp.example.com, which holds the same certificate and completes the handshake with its own key. The browser accepts it, then sends HTTP to a daemon that leaks the request. No key is stolen, but it needs the same network position as everything above. This was mostly fixed server side in 2021.
So the risk of wildcards is real, but small. And it didn’t keep people from using them.
Why everyone still uses wildcards
Say you have 40 subdomains. That could be 40 certificates. Or it could be 1. One validation, one renewal date, one thing to remember, instead of 40 expirations scattered across the calendar.
In 2021, renewal was mostly manual. The advice asked IT to take a sporadic, boring chore and multiply it by 40. A missed renewal is an outage, and 40 renewals is 40 chances to miss one. The real risk of outage wasn’t worth the theoretical risk of key exposure.
Automation should have ended that argument. If a machine does the renewing, 40 certificates cost the same as 1. The outage risk goes away, the tradeoff goes away, and the security advice wins by default.
It didn’t. The most automated certificates in the logs, the 6-day ones, use wildcards a third of the time. Let’s Encrypt, the CA that made automation normal, is 42% wildcard. Cloudflare, which automates more certificates than anyone, hands out a wildcard to every zone by default. The people with the least friction per certificate pick wildcards more often than the people who pay for them one at a time.
That’s because a wildcard makes new hostnames free. New customer, new environment, new internal tool, and it already has a certificate. No issuance step, no DNS challenge, no waiting, and no rate limits when you spin up your 51st subdomain this week.
So the operational case to use wildcards is still true with automation. But the security case to avoid them doesn’t really matter anymore.
Automation makes wildcards safe
Private key exposure has two parts, the impact of a leak and the risk of one happening. Automating certificate renewal and deployment improves both.
The impact of a leak depends on how long the stolen key stays valid and how hard it is to replace. A 1-year wildcard that has to be re-bought, re-validated, and hand-copied to 40 servers is a key you won’t rotate on a suspicion. A 47-day wildcard that one click reissues and redeploys everywhere is a key you can replace anytime you want. The exposure window goes from “until next year’s renewal” to “until somebody wants to.”
The risk of a leak is about sprawl, copying one PEM file to 40 servers by hand, over years, with no records. That’s a deployment problem. The fix is to separate renewal from deployment. Issue the certificate once, in one place. Push it to every host that needs it from there. Keep the list. When the key has to change, change it everywhere on the list, automatically, instead of hunting server by server.
I’m not going to pretend this is a neutral observation. It’s how we built CertKit to work, for exactly this reason. The certificate is renewed centrally and the agent deploys it to each host, so a wildcard on 20 machines is one lifecycle and one audit trail, not 20 copies of a private key that nobody can account for.
The NSA was right that a wildcard key is a bigger target. But the fix shouldn’t have been more certificates and more calendar reminders. It was shorter lifetimes and automation, so the key is small, short-lived, and replaceable. The people running 6-day wildcards already figured that out. The rest of the internet is catching up to them, one 47-day deadline at a time.
CertKit renews your certificates centrally and deploys them to every host, so a wildcard is one lifecycle, not 20 copies of a private key.