A wildcard certificate secures a domain and all of its single-level subdomains with one certificate and one private key. It simplifies management when you have many subdomains, but increases the blast radius of a key compromise. This guide explains how wildcard certificates work, when to use them, and how to manage them securely at scale.
A wildcard certificate is a TLS/SSL certificate that secures a domain and all of its subdomains at a single level using an asterisk (*) as a placeholder in the domain name. A certificate issued for *.example.com will be valid for www.example.com, api.example.com, mail.example.com, and any other single-level subdomain, all with one certificate and one private key.
For organizations managing dozens or hundreds of subdomains, wildcard certificates reduce operational overhead significantly. Instead of requesting, validating, installing, and renewing individual certificates for every subdomain, a single wildcard cert covers them all. This simplification is why wildcard SSL certificates remain one of the most popular choices for web infrastructure, internal services, and development environments.
However, that convenience comes with trade-offs. A single private key protects every subdomain on the certificate. If that key is compromised, every service sharing it is exposed. Understanding when wildcard certificates are the right choice, when they are not, and how to manage them securely is essential for any team responsible for PKI and certificate operations.
A wildcard certificate is a TLS/SSL certificate that uses an asterisk in the leftmost position of the domain name to match any single-level subdomain. The wildcard character is placed in the Subject Alternative Name (SAN) field as a dNSName entry of the form `*.example.com`.
When a client connects to `app.example.com`, it checks the server's certificate. If the SAN contains `*.example.com`, the client matches `app` against the wildcard and the connection proceeds. The same certificate works for `www.example.com`, `staging.example.com`, `intranet.example.com`, or any other name at that level.
Critically, the asterisk only matches a single label. A wildcard certificate for `.example.com` does not cover `example.com` itself (the bare domain), nor does it cover multi-level subdomains like `api.staging.example.com`. The bare domain must be included as a separate SAN entry, and deeper subdomains require their own certificates or an additional wildcard like `.staging.example.com`.
The organization generates a public-private key pair, just as with any TLS certificate. The private key must be stored securely because it will protect every subdomain covered by the wildcard.
A CSR is created with the Common Name or SAN set to `*.example.com`. Most organizations also include the bare domain `example.com` as an additional SAN entry so a single certificate covers both.
The Certificate Authority (CA) validates control over the base domain. For DV wildcard certificates, this typically involves a DNS TXT record or HTTP challenge on the base domain. OV and EV validation add organizational identity checks on top.
The CA signs the certificate and returns it. The certificate and private key are installed on every server or load balancer that hosts subdomains under `example.com`. Each deployment uses the same certificate file but should ideally use independent copies of the private key, protected by access controls or an HSM.
When a browser or API client connects to `api.example.com`, it receives the wildcard certificate. The TLS library compares the requested hostname against each SAN entry. The wildcard pattern `*.example.com` matches any single label in place of the asterisk, so the connection is accepted.
Choosing the right certificate type depends on your domain architecture, security requirements, and operational maturity.
A single-domain certificate offers the smallest attack surface: if its key is compromised, only one service is affected. A wildcard certificate trades that isolation for convenience, covering unlimited subdomains with one certificate. A SAN certificate offers the most flexibility, allowing unrelated domains on a single cert, but every domain must be explicitly listed and the certificate must be reissued when the list changes.
Many organizations combine these approaches. A wildcard cert covers `*.example.com` for general web infrastructure, while individual SAN or single-domain certificates protect high-security services where key isolation is required.
Covers one FQDN (e.g., www.example.com). Minimal blast radius: if its key is compromised, only one service is affected. Available in DV, OV, and EV. Best for individual applications and microservices where key isolation is important.
Covers one domain and all single-level subdomains (e.g., *.example.com). Unlimited subdomains at one level, but does not cover multi-level subdomains like api.staging.example.com. Available in DV and OV only (no EV). High blast radius: all subdomains share one key. Best for organizations with many subdomains under one domain.
Covers multiple unrelated FQDNs in one certificate (5-100+ distinct domains). Each subdomain must be listed explicitly. Available in DV, OV, and EV. Medium to high blast radius depending on SAN count. Best for CDNs, SaaS platforms, and multi-brand hosting.
If your team frequently spins up new subdomains for microservices, staging environments, or customer-facing applications, a wildcard certificate avoids the delay and overhead of issuing a new cert for each one.
Wildcard certs are ideal for non-production environments where `dev.example.com`, `staging.example.com`, and `test.example.com` all need valid TLS without individual certificate management.
When a single domain hosts many subdomains (www, blog, shop, app, docs), a wildcard simplifies configuration on reverse proxies and load balancers.
Corporate intranets and internal APIs under a shared domain benefit from wildcard certificates issued by a private PKI, reducing the management burden without exposing certificates to the public internet.
CAs do not issue EV wildcard certificates. If your compliance or branding requirements demand EV validation, you must use single-domain or SAN certificates.
Payment processing endpoints, authentication gateways, and API services handling sensitive data should have their own certificates with dedicated private keys. Sharing a wildcard key across these services creates unacceptable risk.
If your infrastructure uses deep subdomain hierarchies like `api.us-east.prod.example.com`, a single wildcard certificate cannot cover them. You would need separate wildcards at each level, which quickly negates the management benefit.
If one service is compromised, revoking a wildcard certificate takes down TLS for every subdomain it covers. When granular revocation is a requirement, individual certificates are the safer choice.
The primary security concern with wildcard certificates is the blast radius of a key compromise. Because the same private key authenticates every subdomain, an attacker who obtains it can impersonate any service under the domain, intercept traffic via man-in-the-middle attacks, and decrypt captured sessions.
Store wildcard private keys in Hardware Security Modules (HSMs) or secure key vaults. Never store them in plaintext on application servers, in source code repositories, or in shared configuration files.
Do not copy the same private key file to every server. Use centralized TLS termination at your load balancer or reverse proxy, or deploy separate key copies with strict file-system permissions. The fewer places the key exists, the smaller the attack surface.
Shorter lifespans limit the window of exposure if a key is compromised. Combine wildcard certificates with automated renewal via ACME to make frequent rotation practical.
Certificate Transparency (CT) logs record every publicly trusted certificate. Monitor CT logs for unexpected wildcard certificates issued for your domain, which could indicate a compromised CA account or a misissued certificate.
Use separate wildcard certificates for separate trust boundaries. Production and staging should not share a wildcard key. External-facing and internal services should not share a wildcard key. Each trust boundary gets its own certificate and its own key.
Know in advance how you will revoke and replace a wildcard certificate across all servers if a compromise occurs. Document the process, automate what you can, and test the procedure regularly. A wildcard revocation is an emergency that affects every subdomain simultaneously.
In small environments, managing a handful of wildcard certificates manually is feasible. In enterprise environments with hundreds of domains, multiple CAs, and distributed infrastructure, it becomes a significant operational challenge.
The core difficulties are tracking which wildcard certificates exist, where they are deployed, when they expire, and who is responsible for them. Shadow certificates, procured by individual teams without central oversight, compound the problem. A wildcard certificate that nobody tracks is a wildcard certificate that will expire without warning, potentially causing outages across every subdomain it protects.
Effective management requires three capabilities. First, discovery and inventory: automatically finding every wildcard certificate in your infrastructure, regardless of which CA issued it or which team deployed it. Second, policy enforcement: ensuring wildcard certificates meet organizational standards for key length, algorithm, lifetime, and allowed domains. Third, automated lifecycle management: handling renewal, deployment, and rotation without manual intervention, especially critical as certificate lifespans shrink toward 47 days.
Organizations that rely on spreadsheets or ad-hoc scripts to track wildcard certificates inevitably face renewal failures. A dedicated certificate lifecycle management platform provides the visibility, automation, and policy control needed to operate wildcard certificates safely at enterprise scale.
Complete wildcard visibility — Evertrust CLM discovers every wildcard certificate across your infrastructure through network scanning, CT log monitoring, and endpoint agents. You get a single inventory of all wildcard certs, where they are deployed, and when they expire.
Policy enforcement for wildcards — Define organizational rules that control which domains are allowed to have wildcard certificates, minimum key sizes, maximum lifetimes, and required approval workflows. Evertrust flags non-compliant wildcard certs before they reach production.
Automated renewal and deployment — Evertrust integrates with ACME, EST, and native connectors for web servers, load balancers, and cloud platforms. Wildcard certificate renewals happen automatically, with the new certificate pushed to every deployment point, eliminating the manual coordination that makes wildcard renewals error-prone.
Instant revocation and replacement — If a wildcard private key is compromised, Evertrust lets you revoke the certificate and trigger automated re-issuance and redeployment across all affected servers from a single action, minimizing the downtime window that makes wildcard compromises so dangerous.
