What are Wildcard Certificates

A wildcard certificate is a Transport Layer Security/ Secure Sockets Layer (TLS/SSL) certificate that secures a primary domain and its first-level subdomains with a single certificate.

Instead of purchasing separate certificates for www.example.com, mail.example.com, and blog.example.com, a wildcard certificate issued for *.example.com covers them all. This makes wildcard certificates popular for organizations that manage many subdomains under one domain name.

But convenience comes with trade-offs. A single private key protects every subdomain the wildcard certificate covers, and if that key is compromised, every subdomain is exposed at once.

For enterprises managing network authentication, device security and compliance requirements, the risks of wildcard certificates should be carefully evaluated before deployment.

What Is a Wildcard Certificate?

A wildcard certificate is a digital certificate issued by a Certificate Authority (CA) that uses a wildcard character (*) in the Common Name (CN) or Subject Alternative Name (SAN) field. The asterisk acts as a placeholder, matching any single-level subdomain under the specified domain. The wildcard character must be the leftmost label of the fully qualified domain name (FQDN).

For example, a wildcard SSL certificate issued for *.example.com secures:

• www.example.com
• mail.example.com
• app.example.com
• Any other first-level subdomain added later

A wildcard certificate does not cover multi-level subdomains. A certificate for *.example.com will not secure dev.app.example.com or staging.internal.example.com. Securing those requires either additional wildcard certificates or a multi-domain (SAN) certificate.

Note: Wildcard certificates are available at Domain Validated (DV) and Organization Validated (OV) levels. They cannot be issued as Extended Validation (EV) certificates because EV standards require each FQDN to be individually vetted.

How Does a Wildcard Certificate Work?

When a browser or client connects to a subdomain secured by a wildcard certificate, the TLS handshake follows the same process as any standard SSL/TLS connection:

1. The client requests a secure connection to the server (e.g., mail.example.com).
2. The server presents the wildcard certificate (*.example.com).
3. The client verifies the certificate against its trust store, checking the issuing CA, expiration date and whether the requested subdomain matches the wildcard pattern.
4. If validation passes, the client and server negotiate encryption keys and establish a secure session.

The wildcard matching happens during Step 3. The client compares the requested hostname against the CN or SAN fields. The asterisk matches exactly one label in the DNS name, so *.example.com matches shop.example.com but not www.shop.example.com.

Warning: While installing a single wildcard certificate on multiple servers is technically possible, it can create a security risk.

Best practices dictate each server should use a unique private key to limit the impact if one server is compromised.

The risk becomes clearer in practice.

Suppose www.example.com and mail.example.com run on different hosts. As we’ve learnt, the same certificate and private key can be deployed to both. While this simplifies TLS/SSL encryption across distributed infrastructure, it also means the private key must be copied to every server, which increases the attack surface.

Wildcard Certificate vs. SAN Certificate

Organizations managing multiple domains and subdomains often choose between a wildcard certificate and a SAN certificate, also called a multi-domain certificate. Each has its own strengths.

The table below compares wildcard vs. SAN certificates across certain features:

Feature	Wildcard Certificate	SAN Certificate (Multi-Domain)
Coverage	All first-level subdomains under one domain (*.example.com)	Specific domains and subdomains listed individually (example.com, app.example.org, mail.net)
Flexibility	New subdomains are covered automatically	New domains or subdomains require certificate reissuance
Security	Uses one private key for all subdomains	One private key, but the scope is limited strictly to named entries
EV Support	Not available	Available
Best For	Environments with many subdomains under a single domain	Multiple distinct domains or a specific mix of domains and subdomains

A SAN certificate is generally considered more secure than a wildcard certificate because coverage is restricted to explicitly named domains. There is no open-ended asterisk that an attacker could exploit by spinning up rogue subdomains.

For organizations that need to secure both example.com and example.org, or a combination of domains and subdomains, a SAN certificate provides tighter control.

Some CAs offer certificates that combine wildcard and SAN entries. For instance, a single certificate could include *.example.com in a SAN field alongside example.org and app.example.net. This hybrid approach adds flexibility, though it inherits the security concerns of both types.

When to Deploy a Wildcard Certificate

A wildcard SSL certificate is an appropriate choice in specific scenarios:

• Rapid subdomain growth: If your team frequently creates subdomains for campaigns, staging environments or internal tools, a wildcard certificate eliminates the need to issue a new certificate each time.
• Cost consolidation: Replacing dozens of individual DV certificates with a single wildcard certificate reduces procurement and renewal overhead.
• Simplified certificate management: Managing one certificate instead of many reduces the chance of an expiration-related outage. A single renewal covers the entire subdomain footprint.
• Non-sensitive applications: For subdomains hosting marketing pages, documentation, or public-facing content that does not process authentication credentials, the risk profile of a wildcard certificate may be acceptable.

However, a wildcard certificate is a poor fit when subdomains handle sensitive data, process authentication or run on servers managed by different teams. In those cases, individual certificates or a managed public key infrastructure (PKI) approach provides stronger isolation.

Check out the video below to delve a bit more into what is managed PKI.

Security Risks of Wildcard Certificates

Wildcard certificate offer convenience, but that convenience can introduce security risks. The more subdomains and servers a certificate covers, the greater the potential impact if it is compromised.

Here are some of the major concerns associated with wildcard certificates:

Private Key Compromise

A wildcard certificate uses one private key for every subdomain it secures. If an attacker gains access to that key from any server where it is deployed, they can impersonate every subdomain the certificate covers. This makes wildcard certificates a high-value target.

The private key must be copied to every server that uses the certificate, which increases the number of locations where it can be stolen.

Danger: A breach on a low-priority staging server can compromise production subdomains that share the same wildcard certificate.

The ALPACA Attack

In October 2021, the National Security Agency (NSA) published a Cybersecurity Information Sheet warning organizations about the risks of wildcard TLS certificates. It also highlighted the Application Layer Protocols Allowing Cross-Protocol Attack (ALPACA) technique.

ALPACA exploits the fact that wildcard certificates authenticate multiple services under the same domain.

A man-in-the-middle (MITM) attacker can redirect a TLS connection from an HTTPS server to a non-HTTP service (such as FTP or IMAP) running on a different subdomain, and the TLS session will still validate because the wildcard certificate covers both.

The diagram below shows the simplest form of ALPACA exploitation:

Certificate Revocation Fallout

If a wildcard certificate must be revoked due to compromise, every subdomain it covers goes offline until a new certificate is issued and deployed.

For organizations with dozens of subdomains across multiple servers, this revocation process can take hours or days, creating extended downtime.

Cross-Site Attack Surface

When multiple subdomains share the same certificate, an attacker who compromises one subdomain can more easily pivot to others.

Warning: Shared certificates can facilitate cross-site scripting (XSS), cross-site request forgery (CSRF), and cookie-based attacks across subdomains.

These risks make how certificates are used across subdomains and servers an important security consideration, particularly for organizations managing large numbers of them.

When to Reconsider Wildcard Certificates

The risks of wildcard certificates do not make it unsuitable in every environment. However, they are important to consider when deciding whether a wildcard certificate is the right choice for your organization.

NSA’s October 2021 guidance titled Avoid Dangers of Wildcard TLS Certificates and the ALPACA Technique, recommends:

• Limiting the scope of wildcard certificates wherever possible
• Using security features such as Server Name Indication (SNI) and Application-Layer Protocol Negotiation (ALPN) to reduce the risk of cross-protocol attacks like ALPACA

The case for reconsidering wildcard certificates has also become stronger with changes to certificate lifetimes.

The CA/Browser Forum’s Ballot SC-081v3 reduced the maximum validity period for publicly trusted TLS certificates to 200 days in March 2026, then to 100 days in 2027, and finally to 47 days by 2029. 

As certificate lifetimes shrink, wildcard certificates must be renewed and redistributed much more frequently.

Each renewal requires deploying the updated certificate and its private key to every server that depends on it, increasing operational complexity and the potential impact of configuration errors. The complete schedule is available in the CA/Browser Forum Ballot SC-081v3 announcement.

These industry changes are prompting many organizations to reconsider whether wildcard certificates remain the best long-term approach.

With modern automation protocols such as Automated Certificate Management Environment (ACME) defined in RFC 8555,issuing and managing individual certificates for each application or service has become far easier than it was just a few years ago.

Service-specific certificates:

• Reduce the impact of a compromised private key
• Simplify certificate revocation
• Align more closely with the principle of least privilege

Wildcard certificates still have valid use cases, particularly in environments with large numbers of dynamic subdomains.

However, as certificate renewal cycles shorten and security expectations evolve, organizations should carefully weigh the convenience of wildcard certificates against the operational and security advantages of automated per-service certificate management.

Interested in learning about ACME and automated certificate issuance? Take a look at our video below.

Wildcard Certificate Best Practices

If your organization uses wildcard certificates, you can reduce the associated risks by following these practices:

• Limit scope: Do not use a single wildcard certificate for your entire domain. Separate production, staging, and internal subdomains onto different certificates.
• Protect private keys with HSMs: Store wildcard certificate private keys in a Hardware Security Module (HSM) rather than on disk. This prevents key extraction even if a server is compromised.
• Maintain a certificate inventory: Track every server and subdomain where each wildcard certificate is deployed. You cannot revoke what you cannot find.
• Shorten certificate lifetimes: Use shorter validity periods (90 days or less) with automated renewal via the ACME protocol. This limits the window of exposure if a key is compromised.
• Monitor certificate transparency logs: Watch CT logs for unexpected issuance of certificates matching your wildcard domains.

Evaluate whether you need a wildcard: For many organizations, automated certificate lifecycle management (CLM) through a managed PKI eliminates the operational reasons for choosing wildcard certificates in the first place.

Individual Device Certificates vs. Wildcard Certificates

Wildcard certificates solve a server-side problem: securing subdomains with fewer certificates to manage.

For enterprise network authentication, however, the real challenge is device-level trust, and that is a problem wildcard certificates were never designed to address.

In an enterprise network, every user device that connects to Wi-Fi, VPN or internal applications needs to prove its identity. Password-based authentication is vulnerable to phishing and credential theft. Wildcard certificates do not help here because they authenticate servers, not devices.

Certificate-based authentication through a PKI takes a different approach.

Instead of one certificate covering many subdomains, PKI issues a unique X.509 certificate to each individual user and device. Each certificate has its own key pair, so compromising one device does not affect any other device on the network.

Dive into the core components of PKI and certificate management with the video below.

Certificate-based authentication through a PKI delivers the security properties that wildcard certificates lack, as follows:

• No single point of failure. Each device has its own certificate and private key. Revoking one certificate has zero impact on other devices.
• Identity-bound access. Certificates tie network access to a specific user and device, enabling real-time policy enforcement based on identity and device compliance.
• Automated lifecycle management. With managed PKI, certificate enrollment, renewal, and revocation happen automatically through integrations with MDMs like Intune, Jamf and Google Workspace, and identity providers like Entra ID and Okta.

SecureW2 JoinNow Dynamic PKI automates the issuance of individual device certificates and pairs them with JoinNow Cloud RADIUS for real-time identity lookup at every authentication event.

Instead of managing shared wildcard keys across servers, IT teams manage a fully automated certificate lifecycle where each device carries its own cryptographic identity.

This approach is already being used in large-scale environments. A digital security firm used SecureW2 certificate-based authentication to secure a network of more than 20,000 devices.

Move Beyond Wildcard Certificates with SecureW2 Managed PKI

Wildcard certificates reduce the operational burden of managing TLS/SSL across many subdomains, but they introduce a concentrated risk profile that grows with every server and subdomain they cover.

For server-side TLS on non-sensitive subdomains, a well-managed wildcard certificate with HSM-protected keys and short lifetimes can be appropriate.

For enterprise network authentication and device-level security, wildcard certificates are the wrong tool. Securing Wi-Fi, VPN, and application access requires identity-bound, per-device certificates managed through an automated PKI.

SecureW2 JoinNow Dynamic PKI and Cloud RADIUS deliver exactly this: automated certificate issuance for every device, real-time identity validation at every authentication, and a fully managed cloud platform with no on-premises infrastructure to maintain.

Schedule a personalized demo to see exactly what SecureW2 can do for your organization.

---

Frequently Asked Questions

Does a wildcard certificate cover subdomains at multiple levels?

No. A wildcard certificate for .example.com covers only first-level subdomains such as www.example.com and mail.example.com. It does not cover multi-level subdomains such as dev.app.example.com. Securing deeper subdomain levels requires a separate wildcard certificate (e.g., .app.example.com) or a SAN certificate that lists each FQDN.

Can you get an EV wildcard certificate?

No. The CA/Browser Forum rules prohibit issuing Extended Validation (EV) wildcard certificates. Wildcard certificates are available only at the Domain Validated (DV) and Organization Validated (OV) levels. If your organization requires EV-level trust, you must use individual or SAN certificates.

Is a wildcard certificate less secure than individual certificates?

A wildcard certificate concentrates risk. Because one private key protects every subdomain, a single key compromise exposes them all. Individual certificates isolate risk to one domain or subdomain per key pair. The NSA has recommended that organizations limit wildcard certificate usage and consider individual certificates where possible.

How do you automate wildcard certificate renewal?

Wildcard certificates can be renewed automatically using the ACME protocol with DNS-01 validation. Tools such as Certbot and acme.sh support automated wildcard renewal through DNS API integrations. Let's Encrypt issues free wildcard certificates with 90-day lifetimes, making frequent automated renewal practical.

What is the difference between SSL and wildcard SSL?

An SSL certificate is typically a single-domain certificate: one domain with no subdomains included. But a wildcard SSL certificate secures all first-level subdomains on your domain: example.com and *.example.com (where the asterisk represents the wildcard: any first-level subdomain you add). Plus, wildcard SSL certs extend indefinitely, adding new first-level subdomains automatically.

What is the difference between a wildcard certificate and a SAN certificate?

A wildcard certificate secures all first-level subdomains under one domain using an asterisk (e.g., *.example.com). A SAN certificate lists specific, individually named domains and subdomains (e.g., example.com, app.example.org, mail.example.net). SAN certificates offer tighter security scope and support EV validation, while wildcard certificates offer automatic coverage for new subdomains without reissuance.

What is the difference between a multi-domain SAN certificate and a Wildcard SAN certificate?

A multi-domain subject alternative name (SAN) certificate supports multiple domains and host names on one certificate (e.g., example.com, example.co, differentexample.net). It's also called a multi-domain certificate. A wildcard SAN certificate, or wildcard multi-domain certificate, covers multiple domains, host names and first-level subdomains on one certificate (e.g., *.example.com, *.example.net, *.differentexample.com).