In this article10 sections
A wildcard SSL certificate for *.example.com covers every name exactly one level below the domain, such as www.example.com, shop.example.com and mail.example.com. The star does not match the bare domain example.com, and it does not match two levels down, such as api.staging.example.com. In practice the bare domain is still covered, because certificate authorities add it to a wildcard certificate as a second name. Names two levels down are never covered, and need their own certificate.
This guide explains exactly which names match, how to check what a certificate covers before and after you buy it, and how to choose between a single-name, wildcard, OV and EV certificate.
What the star matches
The star stands for one whole label, the part between two dots. It cannot stand for nothing, for part of a label, or for more than one label.
| Name requested | Covered by *.example.com? |
Why |
|---|---|---|
www.example.com |
Yes | One label in place of the star |
shop.example.com |
Yes | One label |
example.com |
Only if listed separately | The star cannot be empty |
api.staging.example.com |
No | Two labels |
www.shop.example.com |
No | Two labels |
example.org |
No | A different domain |
A browser that receives a certificate whose names do not match the address shows a full-page warning, exactly as if the site had no valid certificate.
Why the bare domain usually works anyway
A certificate holds a list called Subject Alternative Names (SAN), and a browser accepts the certificate if the address matches any entry in that list. When you order a wildcard for *.example.com, the certificate authority issues it with two entries: *.example.com and example.com. That is why a wildcard certificate is described as covering the domain and unlimited subdomains.
The same mechanism explains single-name certificates that cover two names: one issued for www.example.com normally lists example.com as well.
How to check what a certificate covers
For a site that is already live, ask the server for its certificate and print the list of names:
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName -enddateThe answer looks like this:
X509v3 Subject Alternative Name:
DNS:*.example.com, DNS:example.com
notAfter=Oct 9 23:59:59 2027 GMTFor a certificate file you have just been sent, before installing it:
openssl x509 -in certificate.crt -noout -ext subjectAltName -enddateRun the first command against every address you care about, including the bare domain and www. It takes ten seconds and catches the mismatch before a customer does.
Names two levels down
If you use addresses such as client1.app.example.com, you have three options:
- A second wildcard for
*.app.example.com. Right when the names underappare created on the fly, for example one per customer. - Individual certificates for each name. Right when there are only a few and they rarely change.
- Flatten the names to one level:
client1-app.example.cominstead ofclient1.app.example.com. Then the wildcard you already have covers them. This is often the simplest fix for a new project.
Requesting a wildcard certificate
You create a private key and a certificate signing request (CSR) on the server, send the CSR to the certificate authority, and keep the key. Put the star in the common name:
openssl req -new -newkey rsa:2048 -nodes \
-keyout wildcard.example.com.key -out wildcard.example.com.csr \
-subj "/CN=*.example.com"Control panels such as cPanel and Plesk have a form that does the same thing. Two points are specific to wildcards:
- Validation is by DNS record or email, not by file upload. Certificate authorities stopped accepting the “upload a file to your website” method for wildcard certificates in 2021, because proving control of one website does not prove control of every subdomain. Have access to the domain’s DNS ready; if you are unsure where it is managed, see how nameservers and DNS records work.
- The private key is the same on every server that uses the certificate. Store the
.keyfile with permissions600, never send it by email, and if one server is compromised, reissue the certificate with a new key and replace it everywhere.
Which certificate do you need?
| Your situation | Certificate |
|---|---|
One website on example.com and www |
Single-name domain validation (DV) |
| Several subdomains now, more later: shop, blog, app, staging | Wildcard |
| Customers must see who operates the site in the certificate | Organisation validation (OV) |
| Payments or banking, where the strictest company check is expected | Extended validation (EV) |
| A few unrelated domains on one server | One certificate per domain |
All of them encrypt the connection equally. What differs is how many names are covered and how thoroughly the certificate authority checked who you are. DV proves you control the domain and is issued in minutes. OV and EV add a check of your company’s legal details, which takes longer and puts the company name inside the certificate.
Note. There is no such thing as an EV wildcard. The rules for extended validation forbid it. If you need EV on several subdomains, each one needs to be named on the certificate.
Paid certificate or free Let’s Encrypt?
A free Let’s Encrypt certificate encrypts exactly as well as a paid DV certificate, and it is the right choice wherever renewal is automated, which includes cPanel hosting with AutoSSL and a VPS running Certbot. A paid certificate is worth it when you need something the free one does not give you: validity of a year instead of 90 days on a system that cannot renew automatically, an OV or EV certificate that names your organisation, a warranty, a site seal, or support from a person when an installation goes wrong.
Common mistakes to avoid
- Assuming the wildcard covers
a.b.example.com. It never does. - Testing only
www. Check the bare domain and every subdomain in use. - Ordering the wildcard for
*.www.example.comby accident. The common name must be*.example.com. - Copying the private key around by email or chat. Anyone with the key can impersonate every subdomain.
- Forgetting the renewal date on the servers. A wildcard that expires takes every subdomain down at the same moment. Put the date from
-enddatein a shared calendar. - Installing the certificate without the intermediate. Desktop browsers may cope, but many phones and API clients will not. Install the full chain the authority sends you.
SSL certificates from SiteHarbour
We offer SSL certificates from Sectigo, RapidSSL and GeoTrust: single-name DV certificates issued within minutes, a Wildcard certificate covering your domain and unlimited subdomains, and OV and EV certificates that verify your organisation. Every certificate includes free unlimited reissue for its whole validity period, which is what you need when a private key has to be replaced, and validation works by email, DNS record or, for non-wildcard certificates, HTTP file upload.
Frequently asked questions
Does a wildcard certificate cover the www address?
Yes. www is one label, so www.example.com matches *.example.com like any other subdomain.
Can I use one wildcard certificate on several servers?
Yes. Install the same certificate and key on each one. Reissue and replace it everywhere if any of those servers is ever compromised.
Is a wildcard less secure than separate certificates?
The encryption is identical. The risk is concentration: one stolen key exposes every subdomain. Keep the key on as few machines as possible.
Can I add a second domain to a wildcard certificate?
Not to a standard wildcard. It covers one domain and its subdomains. A second domain needs its own certificate.
Does a wildcard help with SEO?
Search engines only care that each page loads over valid HTTPS. Any correctly installed certificate achieves that; the type makes no difference.
The short version: the star is exactly one label. One level down is covered, the bare domain is covered because the authority lists it separately, and two levels down needs another certificate. Check the SAN list with openssl and you never have to guess.