Wildcard certificates — denoted by an asterisk in the subject, like *.yourdomain.com — are a legitimate and widely used tool. Used appropriately, they reduce certificate management overhead for organisations with many subdomains on consistent infrastructure. Used carelessly, they create a single point of failure that exposes everything under a domain to the consequences of a single security incident.
What wildcards actually cover — and what they do not
A wildcard certificate for *.yourdomain.com is valid for any single-level subdomain: api.yourdomain.com, app.yourdomain.com, mail.yourdomain.com. It does not cover yourdomain.com itself (though this is usually added as a SAN), and it does not cover deeper subdomains like api.internal.yourdomain.com.
This means teams sometimes use wildcard certificates in situations where they provide false coverage — believing that *.yourdomain.com covers their entire subdomain namespace, when in fact any second-level subdomain structure is not covered.
The private key blast radius problem
Every TLS certificate has a corresponding private key. The security of the certificate depends entirely on the private key remaining secret. For individual service certificates, a compromised private key is a serious problem — but the scope is limited to the services that use that certificate.
For a wildcard certificate, the scope is every service under the domain. If your wildcard private key is compromised, an attacker can impersonate any subdomain — your main application, your API, your admin interface, your customer portal, your internal tools. All of them, simultaneously, with a certificate that browsers will accept without complaint.
This risk is compounded by the distribution patterns that make wildcards appealing in the first place. The reason teams use wildcards is to avoid managing individual certificates for each service. The certificate and private key get copied to multiple servers, multiple load balancers, multiple environments. Each copy is a potential exposure point. More copies means more risk surface for the key — and the blast radius of a compromise remains the same regardless of where the key leaked from.
The renewal scope problem
When a wildcard certificate is renewed, the new certificate needs to be deployed to every system that uses it. For teams with good infrastructure-as-code practices and centralised certificate management, this is a coordinated deployment. For teams that have been distributing wildcard certificates manually over time, the renewal scope is often unclear.
Which servers have this certificate? Which load balancers? Which CDN configurations? Which third-party platforms where it was uploaded? A manual wildcard certificate distribution history tends to be poorly documented, and renewal deployments often miss some instances — leading to expiry errors on services that were not on anyone's renewal checklist.
When wildcards make sense
Wildcards are appropriate when:
- Services are homogeneous and centrally managed. A CDN or load balancer handling traffic for many services of similar classification, all managed by the same team, is a reasonable wildcard use case. The private key lives in one place, the certificate is managed by one team, and the blast radius of a compromise is well understood.
- ACME automation handles rotation. When a wildcard is renewed automatically via DNS-01 challenge and deployed through automation, the operational convenience is real and the renewal-scope problem is solved by the automation rather than left to manual tracking.
- The subdomain namespace is stable and known. If the organisation has a clear, documented set of subdomains under the wildcard and good visibility into what runs where, the risk is more manageable than in organisations with sprawling, undocumented subdomain structures.
When wildcards create unacceptable risk
Wildcards are inappropriate when:
- Different security zones share the wildcard. Using the same wildcard certificate for production services and development environments means a compromise in the dev environment threatens production. Different security classifications should have separate certificates — and ideally separate subdomains.
- The certificate is distributed to many parties. If the wildcard certificate needs to be uploaded to partner systems, CDN providers, third-party platforms, or contractor environments, each distribution is a private key exposure that you cannot fully control.
- The subdomain space is large and poorly documented. If you do not know what is running under your wildcard, you cannot assess the blast radius of a compromise — and you will almost certainly miss systems during renewal deployments.
- Regulatory requirements mandate certificate isolation. Some compliance frameworks and data protection requirements mandate that systems processing different categories of data use separate cryptographic material. A wildcard shared across systems with different data classifications may violate these requirements.
The monitoring implications of wildcards
Wildcard certificates create specific monitoring challenges. Because a wildcard certificate is valid for any subdomain, certificate monitoring that simply checks for "a valid certificate" on a list of known endpoints may miss services that are using an expiring wildcard but are not in the monitored endpoint list.
Conversely, monitoring that discovers endpoints through CT logs and active scanning will surface all the subdomains using the wildcard — including ones that were not in anyone's inventory. This is often how organisations discover the true scope of a wildcard: when external scanning surfaces services they had forgotten were using it.
How CertControl handles wildcards
CertControl tracks wildcard certificates across all endpoints where they are in use — connecting the certificate fingerprint across multiple services so that the wildcard's expiry is visible in the context of every service it covers. When a wildcard is approaching expiry, the alert surfaces with the full scope of affected services, making the deployment checklist for renewal explicit rather than reconstructed from memory.
The external scanner discovers wildcard-covered services through CT log enumeration and active scanning — so the wildcard's actual scope in production is visible even if the internal inventory is incomplete. Risk scoring applies a higher weight to certificates covering many services, ensuring wildcards with broad scope surface prominently in risk dashboards.