What Is a Wildcard SSL Certificate?
A wildcard SSL certificate secures a domain and all of its first-level subdomains with a single certificate, using an asterisk in place of the subdomain name, such as *.example.com. That one certificate covers www.example.com, shop.example.com, blog.example.com, and any other subdomain at the same level. It saves the cost and hassle of buying and managing a separate certificate for each subdomain, making it ideal for businesses running several subdomains under one main domain.
- Notation
- Asterisk wildcard, e.g. *.example.com in the certificate's common name
- Coverage
- All first-level subdomains of one domain; not multi-level or multiple domains
- Alternative types
- Single-domain and multi-domain (SAN) certificates for other needs
- Validation level
- Usually Domain Validation or Organization Validation (industry-typical)
What is a wildcard certificate? #
A wildcard SSL certificate is a type of TLS certificate that secures an unlimited number of subdomains under a single base domain using a wildcard character. Instead of listing each subdomain individually, the certificate is issued for a name like *.example.com, where the asterisk stands in for any subdomain at that level. This means one certificate simultaneously protects www.example.com, mail.example.com, portal.example.com, store.example.com, and any other subdomain you create later, without needing to reissue anything. It provides the same TLS encryption as any other certificate; the only difference is its flexible coverage. For a business that operates multiple subdomains, perhaps a main site, a client portal, a booking system, and a staging environment, a wildcard certificate consolidates security management into a single item to renew and monitor. To understand the encryption a wildcard certificate provides, see /wiki/what-is-an-ssl-certificate, and for the protocol distinction behind all certificates, /wiki/tls-vs-ssl. Our /services/website-security team advises on whether a wildcard fits your setup.
What exactly does the wildcard cover, and what does it not? #
The wildcard covers all subdomains at one level below the base domain, but the boundaries matter. A certificate for *.example.com secures shop.example.com and blog.example.com, but it does not secure the bare root domain example.com itself unless that is added separately, though most issuers include the root as a courtesy. Crucially, the wildcard only covers one level: *.example.com does not secure a nested subdomain like store.shop.example.com, which would need its own wildcard for *.shop.example.com. It also covers only one base domain; it will not secure a completely different domain such as example.net. If your needs span multiple root domains, a multi-domain or SAN certificate is the right tool instead. Understanding these limits prevents the frustrating surprise of a browser warning on a subdomain you assumed was covered. When we plan a site architecture involving portals, subdomains, or separate apps, our /services/website-security and /services/vps-cloud-setup teams map exactly which certificate type covers which hostnames so nothing is left insecure.
When should a business use a wildcard certificate? #
A wildcard certificate makes sense when you run, or plan to run, several subdomains under one main domain. Common scenarios for local businesses include a public marketing site on www, a client login area on portal, an online store on shop, a booking tool on book, and a staging copy on staging. Buying and renewing a separate certificate for each of these is tedious and easy to let lapse. One wildcard covers them all and any future subdomains you add, which is especially convenient for growing businesses that spin up new subdomains over time. It is also handy for agencies and developers managing multiple environments. That said, if you only have a single site with just www, a simple single-domain certificate, often free and auto-renewing, is perfectly adequate and cheaper. The wildcard's value appears when subdomain count grows. Our /services/client-portals and /services/web-app-development projects frequently use subdomains, so we often recommend a wildcard there, while a straightforward /services/web-design brochure site usually does not need one.
Wildcard versus multi-domain versus single-domain certificates #
There are three common certificate scopes, and choosing correctly saves money and headaches. A single-domain certificate secures exactly one hostname, such as www.example.com, and is the simplest and cheapest option, ideal for a standard business website. A wildcard certificate secures one base domain plus all its first-level subdomains, ideal when you have many subdomains under a single root. A multi-domain certificate, also called a SAN or UCC certificate, secures several distinct domains and hostnames on one certificate, ideal when you own multiple separate domains, such as example.com, example.net, and mybusiness.com, and want them all covered together. Some certificates even combine multi-domain and wildcard capabilities for complex setups. The right choice depends on your domain and subdomain structure. Getting it wrong means either overpaying for coverage you do not need or leaving hostnames unprotected. When we architect hosting for a client, our /services/managed-hosting and /services/website-security teams match the certificate type to the actual set of domains and subdomains in play, and /services/domains-dns-email helps organize the underlying DNS.
How is a wildcard certificate validated and issued? #
Like other certificates, wildcards come in validation levels. Domain Validation, or DV, is the fastest and most common; the certificate authority simply confirms you control the domain, usually via a DNS record or file, and issues quickly. Organization Validation, or OV, adds verification of your business identity, taking longer but signaling more trust. Extended Validation is generally not offered for wildcards because EV requires each hostname to be individually vetted. For most local businesses, a DV wildcard is sufficient and secures every subdomain with the same strong encryption. Issuance requires proving control of the base domain, and because a wildcard secures many subdomains, the private key must be guarded carefully, since a compromise would affect every subdomain at once. Some free certificate providers now offer wildcard DV certificates with automated DNS-based renewal, making them accessible even to small businesses. Our /services/managed-hosting environments can automate wildcard provisioning and renewal, and /services/website-security ensures the private key is stored securely so the broad coverage does not become a broad liability.
What are the security trade-offs of a wildcard? #
The convenience of a wildcard comes with one important trade-off: concentration of risk. Because a single private key secures every subdomain, if that key is stolen or a server hosting it is compromised, an attacker could potentially impersonate any subdomain covered by the certificate. With separate certificates, a breach on one subdomain is contained to that host. This means wildcard keys deserve extra care: store them securely, limit which servers hold copies, rotate them if a compromise is suspected, and monitor certificate usage. For most small businesses running low-risk subdomains, the convenience outweighs the concentrated risk, but for sensitive systems like a client portal handling personal data, some organizations prefer dedicated certificates for isolation. The decision balances operational simplicity against blast radius. Our /services/website-security team helps weigh this for your specific setup, recommending a wildcard where convenience wins and dedicated certificates where a sensitive /services/client-portals or /services/database-services system justifies stronger isolation. Either way, secure key handling is non-negotiable.
How do wildcard certificates fit with DNS and hosting? #
A wildcard certificate works hand in hand with your DNS configuration. Each subdomain the certificate covers must have a corresponding DNS record pointing it to the correct server or service, and the wildcard simply ensures that whichever subdomains exist are all secured. Setting up a new subdomain then becomes a two-part task: add the DNS record so the subdomain resolves, and the existing wildcard automatically covers its encryption with no new certificate needed. This is why wildcards pair so well with dynamic or growing setups. During validation, DV wildcards typically require a specific DNS TXT record to prove control, which is another reason clean DNS management matters. If your DNS is scattered across providers or misconfigured, both validation and subdomain routing can break. Our /services/domains-dns-email service organizes DNS so records and certificates stay in sync, and /services/vps-cloud-setup configures servers to present the wildcard correctly for each subdomain. For the fundamentals of how domain names resolve, see /wiki/what-is-dns.
Do you actually need a wildcard, or is free single-domain enough? #
For many local businesses, the honest answer is that a free, automatically renewing single-domain certificate is all they need. If your entire online presence is one website at www.yourbusiness.com, there is little reason to pay for a wildcard. Free certificate authorities issue and renew single and even wildcard DV certificates at no cost with automation, so cost is rarely the deciding factor anymore; management simplicity is. The wildcard earns its place when you genuinely run multiple subdomains and want one item to monitor instead of many. Before buying, count your subdomains and consider your roadmap. If you expect to add a store, a portal, or a booking subdomain soon, a wildcard prepares you for that growth. If not, keep it simple. Our approach is to right-size the certificate to your real architecture rather than upsell coverage you will not use. A quick /tools/website-grader check confirms HTTPS is active on your existing hostnames, and our /services/website-security team recommends the certificate scope that actually fits your business today and where it is heading.
FAQ
Does a wildcard certificate cover multiple levels of subdomains?
No. A wildcard like *.example.com only covers first-level subdomains such as shop.example.com or blog.example.com. It does not secure nested subdomains like store.shop.example.com, which would need their own wildcard for *.shop.example.com. Our /services/website-security team maps exactly which hostnames each certificate covers so none are missed.
Can one wildcard certificate secure two different domains?
No. A wildcard covers only one base domain and its subdomains. To secure multiple distinct domains like example.com and example.net on a single certificate, you need a multi-domain (SAN) certificate instead. If you own several domains, our /services/domains-dns-email and /services/website-security teams help choose the right certificate type.
Is a wildcard certificate more secure than separate certificates?
Not inherently; it offers the same encryption but concentrates risk. Because one private key secures all subdomains, a key compromise affects every subdomain at once, whereas separate certificates contain a breach. For most low-risk setups the convenience is worth it, but sensitive systems like a /services/client-portals may justify dedicated certificates for isolation.
Do I need a wildcard if I only have one website?
Usually not. A single-domain certificate, often free and auto-renewing, fully secures one site at www.yourbusiness.com. A wildcard only pays off when you run several subdomains under one domain. Our /services/website-security team right-sizes the certificate to your actual architecture rather than selling coverage you will not use.
How does a wildcard certificate get renewed?
It renews like any certificate, on a schedule set by the issuer, often automated through DNS validation. Because one certificate covers all subdomains, you only renew once instead of managing many. Our /services/managed-hosting environments automate wildcard provisioning and renewal so no covered subdomain ever shows an expired-certificate warning.
Does adding a new subdomain require a new certificate with a wildcard?
No, that is the main advantage. Once a wildcard for *.example.com is in place, any new first-level subdomain you create is automatically secured; you only need to add the DNS record so it resolves. Our /services/domains-dns-email service keeps DNS and certificates in sync as you add subdomains.
Was this helpful?