All You Need to Know About Wildcard Certificates

A single compromised private key can quietly expose every subdomain sitting behind it, and that is the trade-off built into every wildcard certificate. Wildcard certificates make securing dozens of subdomains simple, which is exactly why they have become both common and controversial in modern PKI programs.

Key Takeaways

• A wildcard certificate (e.g., *.example.com) secures a domain and all of its first-level subdomains with one certificate and private key, cutting administrative overhead compared to issuing individual certificates.

• Wildcard adoption is significant and growing: wildcard certificates made up 27.4% of all publicly logged TLS certificates in Q2 2026, per Cloudflare Radar Certificate Transparency data, up from 22.3% a year earlier.

• The core risk is concentration: a compromised wildcard private key exposes every subdomain under that certificate at once, and over 70% of organizations reported at least one certificate-related outage in the past year, per CyberArk’s 2025 State of Machine Identity Security Report.

• A SAN (multi-domain) or single-domain certificate limits blast radius but adds management overhead; the right choice depends on how many subdomains you have and how much risk concentration you can tolerate.

• Strong governance (approval workflows, key management, inventory, automated renewal) is what makes wildcard certificates safe to use at all, and that same inventory work is the foundation for post-quantum cryptography (PQC) migration planning.

What is a Wildcard Certificate?

A wildcard certificate, also known as a wildcard SSL certificate, is a type of digital certificate used to secure multiple subdomains of a single domain.

Wildcards are frequently used in Secure Socket Layers (SSL) certificates to extend SSL encryption to subdomains. A traditional SSL certificate is only valid for a single domain, such as www.abc.com. A *.abc.com wildcard certificate can protect all the subdomains under one domain, e.g., cloud.abc.com, shop.abc.com, mobile.abc.com, and other domains.

The asterisk (*) is used as the wildcard character in the certificate. It can represent any single subdomain level. For example, if you have a wildcard certificate for *.abc.com, it will work for any subdomain like finance.abc.com, maketing.example.com, etc.

Wildcard certificates are particularly useful for organizations with numerous subdomains that want to secure them all under a single certificate. They provide encryption and authentication for data transmitted between the user’s browser and the web server, enhancing the security and privacy of web communications. However, it’s essential to manage wildcard certificates carefully because if the private key is compromised, an attacker could potentially use it to impersonate any subdomain under the wildcard domain. Therefore, proper security practices, such as safeguarding the private key and regularly renewing certificates, are crucial when using wildcard certificates.

Wildcard adoption keeps climbing: according to Cloudflare Radar Certificate Transparency data, wildcard certificates accounted for 27.4% of all publicly logged TLS certificates in the second quarter of 2026, up from 22.3% in the same quarter a year earlier (Cloudflare Radar, Q2 2026). That growth tracks the trend driving this article: as organizations run more subdomains per SaaS platform, CDN, and microservice, wildcards remain an easy way to keep TLS coverage from becoming a full-time job.

Wildcard vs. SAN vs. Single-Domain Certificates: How to Choose

Before adopting a wildcard certificate, it helps to see it next to the two alternatives most teams actually choose between: a SAN (multi-domain) certificate and individual single-domain certificates. Each trades coverage, cost, and blast radius differently.

Certificate Type	Domain Coverage	Blast Radius if the Key Is Compromised	Admin Overhead	Best Fit
Wildcard (*.example.com)	All first-level subdomains of one domain	High — every subdomain under the wildcard	Low — one certificate to renew and track	High-subdomain-count environments willing to centralize risk for simplicity
SAN / Multi-Domain	A fixed, named list of domains and subdomains chosen at issuance	Limited to the named hosts on the certificate	Moderate — one certificate, but the list must be updated as hosts change	Organizations that need a handful of specific domains on one certificate without wildcard-style exposure
Single-Domain	One fully qualified hostname	Limited to that one host	High — a separate certificate, and renewal, per host	High-security or compliance-sensitive systems where isolation matters more than convenience

For a deeper comparison of validation requirements, pricing, and CA support for each option, see our full guide: Selecting the Right SSL Certificate: Wildcard vs. SAN (Multi-Domain).

Issues with Wildcard Certificates

There are a few major security issues with the widespread use of wildcard certificates.

False Sense of Security

In high-security systems, for example, ‘https://cloud.abc.com’ or ‘https://personnel_records.abc.com,’ it’s crucial to specify their names explicitly. Wildcard certificates might give a false sense of security, as they don’t guarantee that users are genuinely accessing the intended systems. Users could unknowingly connect to outdated or inactive links or servers that no longer serve any purpose. Using wildcards conceals potential server and DNS errors.

Misuse of Certificates and Their Private Keys

Using wildcard certificates significantly increases the risk of the certificate falling into the wrong hands. Improperly configured wildcard certificates can lead to security vulnerabilities. If they are not correctly set up or their private keys are exposed, attackers could exploit them. This is primarily because wildcard certificates like ‘*.abc.com’ will likely be extensively deployed across various systems, including high-security accounting systems, phone books, routers, and load balancers.

It’s a matter of basic probability: the more individuals involved in installing the same wildcard certificate, the greater the likelihood of it being compromised or leaked. In contrast, named certificates are installed and managed exclusively during designated teams’ setup of specific systems. This approach offers enhanced accountability by a significant margin. Moreover, named Subject Alternative Name (SAN) certificates can only be utilized on designated SAN devices, ensuring error-free connections.

• Security Concerns

  If the private key of a wildcard certificate is compromised, it can potentially be used to impersonate any subdomain under the wildcard domain. This makes it essential to protect the private key rigorously.

• Limited to a Single Level

  Wildcard certificates only cover one level of subdomains. For example, a certificate for *.abc.com would secure subdomains like blog.abc.com and mail.abc.com, but not subdomains like sub.blog.abc.com. To secure multiple levels of subdomains, you would need a multi-level wildcard certificate, which can be more expensive and less commonly available.

• Complexity for Third Parties

  Some third-party services or applications may not support wildcard certificates or may require additional configuration. Compatibility issues may arise in certain situations.

• Risk of Overuse

  Temptation to use wildcard certificates for too many subdomains, potentially increasing the risk if the private key is compromised. It’s essential to limit the use of wildcard certificates to only those subdomains that genuinely need them.

Certificate Outages and Operational Risk

Misused keys aren’t the only operational risk wildcard certificates carry. Certificate-related outages remain one of the most common PKI failures industry-wide: a 2025 CyberArk State of Machine Identity Security Report found that over 70% of organizations experienced at least one certificate-related outage in the past year. Because a wildcard certificate often sits behind many services at once, an expired or misconfigured wildcard doesn’t take down one site — it can take down every subdomain that depends on it at the same time.

Certificate Revocation Complexity

Revoking a wildcard certificate can be more complex than revoking individual certificates. Revocation typically applies to the entire wildcard domain, affecting all subdomains.

Recommendations for Wildcard Certificate Policies

Wildcard certificates can be a convenient solution for securing multiple subdomains within an enterprise-level organization. However, they also introduce certain security and management challenges. Governance matters here because most organizations still handle this manually: a February 2026 SwissSign survey found that 90% of organizations with more than 500 employees still manage certificates at least partially manually — exactly the condition under which a wildcard misconfiguration goes unnoticed. Here are some policies that an enterprise-level organization should consider when implementing wildcard certificates in its environment:

Governance and Approval

• Approval Process

  Establish a process for requesting, validating, and approving wildcard certificate requests. Must use the exception process to request wildcard certificates, which means requesting a wildcard certificate is not the standard practice or the default way of obtaining certificates within the organization; it has to follow an exception process, such as approval of leadership (Directors, VP).

• Certificate Management Policies

  Create a clear policy for the wildcard certificate issuance, renewal, and revocation in your “Certificate Policy (CP)” and “Certificate Practice Statement (CPS).” Specify who is responsible for managing the certificates.

• Compliance and Industry Standard

  Ensure that wildcard certificate management practices align with industry standards and regulations relevant to your organization, such as PCI DSS or HIPAA.

Identification, Naming, and Documentation

• Identify Subdomains

  Identify all subdomains that the wildcard certificate will cover. Determine which subdomains must be secured and ensure they adhere to your organization’s naming conventions.

• Subdomain Naming Conventions

  Establish clear naming conventions for subdomains that wildcard certificates will secure. This helps ensure consistency and clarity in certificate management.

• Provide Accurate Information

  Ensure that all information provided during the certificate issuance process is accurate, up to date, and includes all endpoints intended for the certificate. This includes a proper naming convention for the certificate (according to organizational preferences and requirements), contact information, organization details (if applicable), domain ownership information, and providing justification to request a certificate.

• Inventory and Documentation

  Maintain an up-to-date inventory of all wildcard certificates in use within the organization. Document certificate details, including expiration dates, associated subdomains, and responsible parties.

Technical and Access Controls

• Key Management

  Implement strong key management practices, including the secure generation and storage of private keys associated with wildcard certificates. Regularly rotate keys and update certificate configurations, including certificate templates and protocol compatibility, to stay ahead of potential vulnerabilities.

• Access Control

  Limit access to wildcard certificates and their private keys to authorized personnel only. Enforce strict access controls and authentication mechanisms to prevent unauthorized access.

• Secure Storage

  Store wildcard certificates and their private keys in a secure, offline, or hardware security module (HSM) protected environment. Encrypt and back up certificate data to prevent data loss.

Lifecycle, Monitoring, and Risk Reduction

• Certificate Revocation Policy

  Define a clear process for revoking wildcard certificates in case they are compromised or no longer needed. Ensure that revoked certificates are promptly removed from all relevant systems.

• Certificate Renewal Process

  Establish a process for timely certificate renewal to avoid service disruptions due to expired certificates. Automate certificate renewal where possible to reduce manual errors.

• Regular Security Assessment

  Conduct regular security assessments and penetration testing to identify vulnerabilities related to wildcard certificates and their usage.

• Security Awareness and Training

  Educate employees about the importance of wildcard certificate security and the risks associated with mishandling them.

• Usage of Wildcard Certificates

  Usage of wildcard certificates should be avoided whenever possible. Create a comprehensive plan for gradually decreasing the usage of wildcard certificates when they come up for renewal.

Recommendation for Future Action

Below recommendation will be useful for the organization’s future action for wildcard certificates.

Interim Measure

Minimize the individuals with access to wildcard certificates, ideally limiting it to fewer personnel. Implement strict controls over the handling of the private key and certificate, treating them with the utmost security. Avoid electronic transmission and HDD storage; instead, opt for secure physical storage methods like HSM stored in a secure location. Ensure that each certificate installation is set as “non-exportable” to prevent potential leaks.

Medium Term

Reduce the use of wildcard certificates to the fewest number of systems possible. Use named certificates everywhere possible. This implies knowing where the wildcards are installed and planning for their replacement (if possible).

Long-Term Strategy

Implement a requirement that all wildcard certificates must be generated or renewed exclusively through an automated process, with zero personnel interaction. It’s essential to note that this transition will necessitate significant planning and preparation. This shift is no longer optional on a long enough timeline: the CA/Browser Forum’s maximum public TLS certificate validity dropped to 200 days in March 2026 and is scheduled to fall to 100 days in 2027 and 47 days by 2029, which makes manual wildcard renewal untenable at scale regardless of policy preference.

Wildcard Certificates and Crypto-Agility: Why This Connects to Your PQC and CBOM Strategy

Here’s the part most wildcard certificate guidance leaves out: the key behind that certificate doesn’t stay relevant forever. Every RSA or ECDSA key protecting a wildcard certificate today is a candidate for migration once post-quantum cryptography (PQC) algorithms become the baseline, and an organization that doesn’t already know where its wildcard certificates live and what algorithms they use isn’t ready to plan that migration.

This is why we treat wildcard certificate governance as a subset of a bigger discipline: cryptographic inventory. A Cryptographic Bill of Materials (CBOM) gives you the same visibility your PQC roadmap needs — which keys, certificates, and algorithms exist, where they’re used, and which ones are quantum-vulnerable — starting with the wildcard certificates that already carry the widest blast radius if something goes wrong. We cover why most inventories miss this in The Cryptographic Blind Spot Hiding in Your Own Infrastructure.

Once that inventory exists, the migration itself needs sequencing, not a big-bang cutover. Our guide, PQC Migration in 2026: Building a Roadmap That Survives Contact With Production, walks through how to prioritize which certificates and keys to migrate first — and a wildcard certificate protecting a dozen production subdomains is a strong candidate for that priority list.

Conclusion

Organizations should implement strong certificate management policies and security practices (CP/CPS), regularly audit and monitor the wildcard certificate usage, and consider alternatives such as using separate certificates for critical subdomains or implementing more granular security controls where necessary. While wildcard certificates can be a valuable tool, they should be used thoughtfully and securely within an organization’s overall security strategy.

If you’re auditing an existing wildcard certificate right now, our free OpenSSL CSR & Certificate Decoder will show you exactly which subdomains, validity dates, and algorithms it covers before you decide whether it still belongs in your environment.

Frequently Asked Questions

A few questions come up often when teams evaluate wildcard certificates:

What is a wildcard certificate used for?

A wildcard certificate secures a domain and all of its first-level subdomains with a single certificate and private key. Instead of issuing separate certificates for blog.example.com, shop.example.com, and mail.example.com, an organization can deploy one *.example.com certificate across all of them, which is why wildcard certificates are common on sites with many subdomains.

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

A wildcard certificate covers unlimited first-level subdomains of one domain using an asterisk, while a SAN (multi-domain) certificate lists a fixed set of specific domain and subdomain names chosen at issuance. SAN certificates limit blast radius to the named hosts; wildcard certificates trade that granularity for broader, simpler coverage.

Can a wildcard certificate cover multiple levels of subdomains?

No. A standard wildcard certificate for *.example.com secures only first-level subdomains like blog.example.com, not nested subdomains such as sub.blog.example.com. Securing multiple subdomain levels requires either a separate wildcard for each level or a multi-level wildcard arrangement, which is more expensive and far less commonly issued by public CAs.

Is a wildcard certificate less secure than individual certificates?

A wildcard certificate isn’t inherently weaker cryptographically, but it concentrates risk: if its private key is compromised, an attacker can impersonate every subdomain under that domain at once. Named certificates limit a compromise to a single host, which is why many security teams reserve wildcards for lower-risk, non-critical subdomains.

Do wildcard certificates still work under the CA/Browser Forum’s shorter validity rules?

Yes. Wildcard certificates follow the same maximum validity schedule as any public TLS certificate, capped at 200 days as of March 2026 and dropping to 100 days in 2027 and 47 days by 2029. Because wildcards often protect many systems at once, automating their renewal matters more, not less, under these shorter cycles.