Wildcard certificates: one certificate for every subdomain

What is a wildcard certificate?

A wildcard TLS certificate contains a wildcard DNS identifier, typically in the Subject Alternative Name (SAN) extension. The wildcard character substitutes for a single DNS label. A wildcard TLS certificate can represent many hostnames at one DNS level with a single wildcard identifier such as *.yourdomain.com. That can reduce certificate sprawl and accommodate new first-level subdomains without changing the wildcard name. But wildcard coverage also increases the scope of a certificate and, if the same private key is distributed broadly, can increase the impact of key compromise or operational failure.

For *.yourdomain.com:

www.yourdomainexample.com - covered
api.yourdomain.com - covered
portal.yourdomain.com - covered
login.yourdomain.com - covered
dev.api.yourdomain.com - not covered because it is two labels below yourdomain.com

Wildcard certificates

Wildcard coverage is name coverage - not automatic deployment

A wildcard certificate does not automatically create, install, or configure a certificate on every subdomain. It simply allows the certificate to be valid for hostnames that match the wildcard pattern. The certificate and corresponding private key still have to be available at the TLS termination point that serves each hostname, unless TLS terminates centrally at a shared proxy, load balancer, CDN, or gateway.

Note: A wildcard can cover a hostname that did not exist when the certificate was issued, but the new service still requires a valid TLS deployment. Wildcard name coverage removes the need to add that first-level hostname to the certificate; it does not remove requirements for installation, binding, key protection, or validation.

When wildcard certificates are a good fit

Many first-level subdomains belong to the same operational and security boundary.
New first-level subdomains are created frequently and explicit hostname-by-hostname certificate changes would add unnecessary friction.
TLS terminates at a small number of well-controlled gateways, load balancers, or reverse proxies, limiting how widely the wildcard private key must be distributed.
The organization can automate renewal, deployment, and live-endpoint validation for every location where the wildcard certificate is used.
The blast radius of revocation, expiration, misdeployment, or key compromise is understood and accepted.

When a wildcard is probably the wrong boundary

Subdomains are owned by unrelated teams or have materially different security requirements.
One wildcard would span internet-facing services, internal administrative services, development environments, or different application protocols without a strong reason.
The same wildcard private key would need to be copied to a large number of independently administered servers.
High-value services need independent key rotation, revocation, incident response, or HSM/KMS protection.
You need names across unrelated base domains; explicit SANs or separate certificates are generally a better fit.

The real security risk is private key sprawl

The primary wildcard risk is not the asterisk itself. Risk increases when a certificate with broad name coverage is paired with a private key that is distributed across many systems. If an attacker obtains that private key, they may be able to impersonate any hostname within the certificate's wildcard scope, depending on the surrounding network and application controls.

If the same wildcard certificate and private key are copied to ten servers, a compromise of any one server can expose the shared key used by the others. This is why broad wildcard deployment can turn a local host compromise into a domain-wide credential incident.

Deploying wildcard certificates across multiple systems

There are two fundamentally different designs, and they should not be treated as equivalent:

Reuse one certificate and private key on multiple endpoints. This is operationally simple but enlarges the key-compromise and coordinated-renewal blast radius.
Issue separate certificates - potentially with the same wildcard identifier - using distinct private keys for separate endpoints or trust boundaries. This preserves wildcard name flexibility while improving key isolation, though it increases the number of certificate objects to manage.

DigiCert Trust Lifecycle Manager can centrally automate certificate lifecycle operations across supported web servers, network appliances, cloud services, and vaults. Agents manage supported server hosts; sensors and connectors manage supported network appliances and cloud services. Use the supported automation pattern for the actual TLS termination point rather than assuming every wildcard deployment should distribute one identical private key everywhere.

CAA and wildcard issuance

Certificate Authority Authorization (CAA) can place additional controls on wildcard issuance. The CAA issuewild property can specifically authorize or restrict CAs for wildcard certificates. Organizations using CAA should test and document the intended policy for both wildcard and non-wildcard names rather than assuming an issuewild record alone describes the entire order.

Shorter public TLS lifetimes increase the value of automation

Wildcard certificates are subject to the same public TLS lifetime limits as other publicly trusted TLS certificates. At publication time in August 2026, DigiCert limits newly issued public TLS certificates to 199 days. DigiCert's published roadmap moves to a 99-day maximum in early 2027 and a 46-day maximum in early 2029, subject to final implementation dates and current CA/Browser Forum requirements.

The shorter lifecycle does not make wildcard certificates inherently better or worse. It makes reliable automation, inventory, ownership, deployment validation, and key isolation more important because every certificate population will rotate more frequently.

Supplemental resources

Frequently asked questions

Does a wildcard certificate automatically cover subdomains created later?

The wildcard name can match a new first-level subdomain without reissuing the certificate solely to add that hostname. However, the certificate still has to be deployed at the TLS termination point for the new service, and the service must satisfy normal key, binding, and configuration requirements.

Are SAN certificates safer than wildcard certificates?

Not automatically. Explicit SANs reduce name scope because only listed hostnames are valid, but one SAN certificate can still contain many names and share one private key. If compromise isolation is the priority, use separate certificates and private keys for meaningful service or trust boundaries.

What are the biggest security risks of wildcard certificates?

The principal risks are broad name scope, broad private-key distribution, and a large failure domain. If one shared wildcard private key is compromised, an attacker may be able to impersonate other hostnames covered by that certificate. Poorly scoped wildcard use across unrelated application protocols can also contribute to ALPACA-style cross-protocol risk.

How should I deploy a wildcard certificate across multiple servers?

First decide whether the servers should share a private key at all. Reusing one certificate and key is simple but increases blast radius. Separate certificates with distinct keys can use the same wildcard identifier while improving isolation. Trust Lifecycle Manager can automate supported target systems using agents for servers and sensors/connectors for supported appliances and cloud services.

What happens if a wildcard certificate expires or is revoked?

Every service currently relying on that certificate can be affected at once. The exact service impact depends on where the certificate is deployed and whether other certificates are available. This shared failure domain is one reason to automate renewal and verify deployment on every endpoint before the old certificate expires.

Does revoking one wildcard certificate revoke every certificate for the domain?

No. Revocation applies to the specific certificate being revoked. Other independently issued certificates for the same wildcard or individual hostnames remain separate certificate objects. However, every endpoint using the revoked certificate will be affected.

Should I use one wildcard for production, development, and internal services?

Usually not merely because the names share a parent domain. Separate environments and trust levels are often better represented by separate certificates and private keys. Use ownership, key protection, application protocol, exposure, and incident blast radius to define certificate boundaries.

Ready to evaluate your environment?

See how DigiCert Trust Lifecycle Manager can support certificate lifecycle automation across protected web servers and the rest of your enterprise certificate estate.

Explore DigiCert Trust Lifecycle Manager Talk to DigiCert