What are Wildcard Certificates

A wildcard certificate is a TLS/SSL certificate that secures a primary domain and all of 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 deserve serious evaluation 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 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.

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 fully qualified domain name (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.

A single wildcard certificate can be installed on multiple servers. While technically possible, security best practices dictate that unique keys should be used per server to maintain isolation. If www.example.com and mail.example.com run on different hosts, the same certificate and private key can be deployed to both. This simplifies TLS/SSL encryption across distributed infrastructure but 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 (Subject Alternative Name) certificate, also called a multi-domain certificate. Each approach has distinct strengths.

Wildcard vs. SAN Certificates

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 PKI approach provides stronger isolation.

Security Risks of Wildcard Certificates

The convenience of a wildcard certificate introduces security risks that scale with the number of subdomains and servers it covers. 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. 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 NSA published a Cybersecurity Information Sheet warning organizations about the risks of wildcard TLS certificates and the ALPACA (Application Layer Protocols Allowing Cross-Protocol Attack) technique. ALPACA exploits the fact that wildcard certificates authenticate multiple services under the same domain. A man-in-the-middle 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 NSA advisory recommended that organizations limit the scope of wildcard certificates, use Application-Layer Protocol Negotiation (ALPN), and consider replacing wildcards with individual certificates where possible.

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. Shared certificates can facilitate cross-site scripting (XSS), cross-site request forgery (CSRF), and cookie-based attacks across subdomains.

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 actually need a wildcard. For many organizations, automated certificate lifecycle management 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. But for enterprise network authentication, 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 Public Key Infrastructure (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.

This approach 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.

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-premise 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 like 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 like 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 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.