Wildcard SSL certificate
A cert valid for *.example.com — covering any single-label subdomain. Useful for tenant subdomains; not useful for unrelated customer domains.
A wildcard SSL certificate is an X.509 certificate whose subject name uses a * in the leftmost label — *.example.com — so it validates any single-label subdomain: acme.example.com, shop.example.com, api.example.com. One certificate, unlimited subdomains, no reissue when you add another.
The two things it does not do catch people out constantly: it does not cover the apex example.com, and it does not cover multi-label names like a.b.example.com. Both follow from the same rule, and both are visible in real production certificates.
Domainee is a custom domains API for SaaS with a native MCP server — 50 domains and 100 GB free.
The wildcard matches exactly one label
RFC 6125 allows the wildcard only as the complete leftmost label, and it substitutes for exactly one label. Not zero, not two.
Zero is why the apex is excluded: example.com has nothing in front of it for the * to stand in for. Two is why *.example.com fails on a.b.example.com — you would need *.b.example.com for that.
You can watch both rules being worked around in the wild. Certificates pulled from production on 2026-08-26:
| Host | CA | Names on the certificate |
|---|---|---|
notion.so | Google Trust Services | notion.so, *.notion.so, *.dev.notion.so, *.stg.notion.so, *.www.notion.so |
app.slack.com | Let's Encrypt | *.slack.com, slack.com |
vercel.com | Let's Encrypt | *.vercel.com, vercel.com |
figma.com | Amazon | *.figma.com, figma.com |
shopify.com | Google Trust Services | shopify.com, *.shopify.com |
linear.app | Let's Encrypt | *.client-preview.linear.app, linear.app |
github.com | Sectigo | github.com, www.github.com |
stripe.com | DigiCert | stripe.com, www.stripe.com |
Two patterns fall straight out of that table.
The apex is always listed separately. Six of the eight carry a wildcard, and every one of those six also carries the bare domain as its own name. Nobody relies on the wildcard to cover the apex, because it cannot. If an apex fails TLS while every subdomain succeeds, this is almost always why — and the browser will report it as ERR_CERT_COMMON_NAME_INVALID.
One wildcard per level. Notion carries four wildcards on one certificate because *.notion.so does not reach dev.notion.so's children. Each additional level of nesting is another name you have to enumerate and keep renewed.
Also worth noting: github.com and stripe.com use no wildcard at all. Two names, apex and www. A wildcard is not a default worth adopting — it is a specific answer to a specific problem.
When a wildcard is right for SaaS, and when it is the wrong tool
The deciding question is who owns the domain your customers are reached on.
Tenant subdomains of your own domain — acme.yourapp.com, shop.yourapp.com. A wildcard is exactly right. One *.yourapp.com covers every tenant that exists and every tenant you have not signed yet, with no issuance at signup time at all. This is what Slack, Vercel and Shopify are doing in the table above, and it is the usual shape of
multi-tenant custom domains before customer-owned domains enter the picture.
Customers bringing their own domains — acme.com, shop.com. A wildcard is structurally useless. Wildcards are scoped to one registered domain, and these are unrelated registered domains you do not control. You need per-domain issuance: a single-name certificate for each, or a SAN certificate grouping several. This is the BYOD case, and it is what a custom domain API exists to automate.
Most products end up doing both: a wildcard for the tenant-subdomain default, and per-domain certificates for the customers who bring their own. Those are two different provisioning paths with different failure modes, and it is worth building them as such rather than pretending one covers the other.
The rate limit is the real argument for a wildcard
Cost is the usual reason given for wildcards, and since Let's Encrypt issues them free it is not much of an argument any more. The argument that actually holds is throughput.
Let's Encrypt's published limits, checked on 2026-08-26:
| Limit | Value |
|---|---|
| New certificates per registered domain | 50 per 7 days |
| New orders per account | 300 per 3 hours |
| New certificates per exact same set of identifiers | 5 per 7 days |
| Identifiers per certificate | up to 100 |
The first row is the one that bites, and only in one of the two designs above.
Tenant subdomains share a budget. acme.yourapp.com, shop.yourapp.com and every other tenant all sit under the registered domain yourapp.com. If you issue a single-name certificate per tenant, all of them draw on the same 50-per-week allowance. Onboard the 51st tenant in a week and issuance fails — not because of anything that tenant did. One *.yourapp.com wildcard removes the problem completely: no per-tenant issuance, so nothing to rate limit.
Customer-owned domains do not. acme.com and shop.com are separate registered domains, each with its own 50-per-week allowance. You would have to issue 50 certificates for one customer's domain inside a week to hit it. In the BYOD design the limit is essentially unreachable, which is the opposite of what most people assume when they read it.
One correction worth carrying, because plenty of write-ups state this wrong: the limit is on new certificates, not on certificates in existence. Renewals are exempt from it. Renewals coordinated through ACME Renewal Info (ARI) are exempt from every rate limit; renewals detected the older way, by requesting the exact same set of identifiers, are exempt from the per-registered-domain and per-account order limits. So a steady state of thousands of live certificates renewing on schedule is fine. It is bursty first-time issuance that fails.
What a wildcard hides, and what per-name certificates publish
Every certificate a public CA issues is published to Certificate Transparency logs. The logs are public, permanent and searchable by anyone.
What gets published is the name list — the same list in the table above. That has a consequence people rarely weigh when choosing between a wildcard and per-name issuance:
*.yourapp.compublishes one string, no matter how many tenants sit behind it. Your tenant list is not in the log because it was never in a certificate.- A single-name certificate per customer domain publishes every customer hostname, permanently.
So if you issue per-customer certificates, your customer list is public. Anyone can enumerate it. That is not a reason to avoid BYOD — you have no alternative there, since the customer's domain has to be on a certificate for TLS to work at all — but it is a reason to know it is happening, and to not be surprised when a competitor or a journalist reads it back to you. Treat "who our customers are" as public information from the day you ship custom domains.
The tenant-subdomain case is where you have a genuine choice, and the wildcard is the private option.
Issuing a wildcard requires DNS-01
Wildcards can only be validated through the DNS-01 challenge of the ACME protocol. The HTTP-01 challenge serves a token from one specific hostname, which proves control of that hostname and nothing about its siblings — not enough to justify a certificate matching every sibling. DNS-01 publishes a TXT record in the zone itself, which is a claim over the whole zone.
The practical consequence: issuing a wildcard needs programmatic access to the zone's DNS. For your own domain that is fine. For a customer-owned domain you usually do not have it, which is another reason the BYOD path lands on single-name certificates validated over HTTP-01 instead. Full mechanics in how SSL works for custom domains.
The SAN alternative, and its coupling problem
A SAN or multi-domain certificate lists unrelated hostnames explicitly. Let's Encrypt allows up to 100 identifiers on one certificate, so grouping customers onto shared certificates looks like an efficient way to cut issuance volume.
It introduces a coupling that is easy to miss. A certificate is issued or renewed as a unit, and every name on it must validate. Put 100 customer domains on one certificate and a single customer who removes their CNAME, lets their domain expire or breaks their DNS blocks renewal for all 100. You then have 99 working customers facing an expiry countdown caused by someone else.
If you group, group small, and build the renewal path so a failing name is dropped from the set rather than failing the batch. Watch for dangling records from departed customers for the same reason — a name nobody is using is still a name that has to validate.
| Wildcard | SAN / multi-domain | Single-name per host | |
|---|---|---|---|
| Covers unrelated domains | No | Yes | Yes |
| New hostname needs reissue | No | Yes | Yes |
| Validation | DNS-01 only | Either | Either |
| Hostnames exposed in CT | No | Yes | Yes |
| One bad name breaks renewal | n/a | Yes, for the whole cert | No |
| Fits tenant subdomains | Yes | Poorly | Poorly |
| Fits customer-owned domains | No | Yes, with care | Yes |
Checking what you have
SNI is what lets one IP present the right certificate for each hostname, so a mis-scoped wildcard shows up as the wrong certificate rather than no certificate. If a host is failing, read the name list on the certificate it actually served before assuming the handshake is at fault — the SSL certificate checker shows the names, issuer and expiry, and certificate renewal covers the timing side — an expired certificate and a mis-scoped wildcard look similar in a browser and are not the same problem. Domainee handles both paths, wildcard and per-customer, on its SSL layer.
FAQ
Does a wildcard certificate cover the apex domain?
No. *.example.com substitutes for exactly one label and the apex has none. Every production certificate that uses a wildcard also lists the bare domain separately — six of six wildcard-using hosts measured on 2026-08-26 did exactly that. Add the apex as its own name on the same certificate.
Does a wildcard cover multi-level subdomains?
No. *.example.com matches api.example.com but not v2.api.example.com. Each level needs its own wildcard, which is why notion.so carries *.notion.so, *.dev.notion.so, *.stg.notion.so and *.www.notion.so on one certificate.
Can I get a free wildcard certificate? Yes. Let's Encrypt issues wildcards at no cost, but only through the DNS-01 challenge, since a wildcard cannot be validated over HTTP-01. That means you need programmatic access to the zone's DNS, which is the real gate rather than price.
When should I use a wildcard instead of a SAN certificate? Use a wildcard when the hostnames are subdomains of one domain you control and new ones appear often — it needs no reissue. Use a SAN certificate when the hostnames are unrelated domains you can enumerate. Wildcards cannot span registered domains, so customer-owned domains always need the SAN or single-name route.
Will a wildcard help me avoid Let's Encrypt rate limits?
In the tenant-subdomain design, yes, decisively. Single-name certificates for acme.yourapp.com, shop.yourapp.com and so on all count against one 50-per-registered-domain-per-7-days budget, so per-tenant issuance caps new onboarding at 50 a week. One wildcard needs no per-tenant issuance at all. For customer-owned domains each domain has its own budget, so the limit rarely binds either way.
Do my customers' domain names end up public if I issue certificates for them? Yes. Every publicly trusted certificate is logged to Certificate Transparency, and the log entry contains the hostnames. Issuing per-customer certificates makes your customer list permanently searchable. A wildcard over your own tenant subdomains publishes one string instead, so it is the private option where you have the choice.