Do Subdomains Need Their Own SSL Certificate? What Each Option Covers
Every subdomain served over HTTPS needs to be covered by a certificate, but it does not need a certificate of its own. A wildcard certificate covers a whole level of subdomains at once, and a multi-domain certificate covers a named list. Whether you need separate certificates depends entirely on which of those you are using and how your names are structured.
This article covers what a certificate for example.com does and does not cover, the one-level rule that catches almost everyone with wildcards, the apex gap that surprises the rest, and how to decide between separate certificates, a wildcard, and a multi-domain certificate for a given setup.
What a certificate actually covers
A certificate is valid for the names listed inside it, in the Subject Alternative Name field, and nothing else. Browsers check the hostname you typed against that list, and a mismatch produces a warning regardless of whether the certificate is otherwise perfectly valid and issued by a trusted authority.
The consequence is stricter than most people expect. A certificate issued for example.com does not cover www.example.com. They are different hostnames, and the fact that one looks like a version of the other means nothing to the matching logic. In practice this rarely bites, because certificate authorities have long issued the www variant alongside the apex as a convention, and most issuance flows add both. But it is a convention, not a rule, and a certificate covering only the apex will fail on www exactly as it would on any unrelated name.
Beyond that pair, nothing is implied. A certificate for example.com does not cover api.example.com, shop.example.com, or anything else. Each of those either appears in a certificate's name list, is matched by a wildcard, or gets a warning. Our explainer on how SSL works covers the handshake step where this matching happens.
The one-level rule, and the apex gap
A wildcard certificate for *.example.com is the usual answer to subdomain sprawl, and it works well, with two limits that account for most of the confusion in this area.
The first is the one-level rule. A wildcard matches exactly one label in place of the asterisk. So _.example.com covers api.example.com, shop.example.com, and staging.example.com, and does not cover test.api.example.com, because that name has an extra level. Covering the deeper level needs its own wildcard, issued for _.api.example.com. Teams that adopt a nested naming scheme after buying a wildcard tend to discover this the first time they deploy something two levels down.
The second is the apex gap. A certificate issued strictly for *.example.com does not cover example.com itself, because the bare domain has no label where the asterisk sits. Most certificate authorities handle this by adding the apex as an additional name automatically, and many issuance flows require you to request both explicitly. It is worth verifying rather than assuming, because the failure mode is that your subdomains all work and your main site throws a warning, which is a strange enough symptom to waste an afternoon on.
Together these give you the shape of what a wildcard is for. It is excellent for a flat naming scheme under one domain, particularly when subdomains are created frequently, because a new name is covered the moment it exists with no reissue required. It is a poor fit for deep hierarchies and no help at all across separate domains.
When separate certificates are the better answer
Three situations argue for individual certificates over a wildcard, and they are worth recognising before you buy.
The first is key exposure. A wildcard puts one private key in every place that serves a covered subdomain. If those subdomains live on different servers, run by different teams, at different trust levels, a compromise anywhere is a compromise of everything the wildcard covers. Some security policies prohibit wildcards on exactly this basis, and the objection is sound rather than theoretical. Named certificates fail smaller.
The second is automation. If you already run automated issuance and renewal, the administrative saving from a wildcard mostly evaporates, because the work a wildcard saves is the work automation was already doing. Free automated issuance has made per-name certificates cheap enough that the historical cost argument for wildcards has largely gone with it.
The third is validation method. Wildcard certificates require DNS-based validation, since there is no single host to serve an HTTP challenge for an unlimited set of names. If your DNS provider has no API, or your team cannot automate DNS record creation, a wildcard turns every renewal into a manual task. That is an unattractive trade when validation reuse windows are shrinking and renewals are becoming more frequent.
The operational answer, whichever you choose
Whatever the structure, the thing that actually causes outages is not the choice between certificate types. It is losing track of which certificate covers which name and when each one expires.
A wildcard concentrates that risk in a useful way, because there is one expiry date to know, and it also concentrates the blast radius, because missing it takes down every subdomain simultaneously. Separate certificates spread the risk and multiply the dates, which is safer per incident and much easier to lose track of. Neither structure removes the need to know what is deployed where.
That is worth stating plainly because certificate inventories drift. A subdomain spun up for a project two years ago is still resolving, still serving, and still using a certificate nobody has thought about since. Checking every hostname you actually serve, rather than every certificate you believe you bought, is the difference between an inventory and a guess.
Common mistakes in subdomain certificate planning
Assuming a wildcard covers every subdomain. It covers exactly one level. A name like test.api.example.com needs its own wildcard for *.api.example.com, and finding this out during a deploy is the usual sequence.
Forgetting the bare domain. A certificate for *.example.com alone does not cover example.com. Most CAs add the apex automatically, but confirm it rather than assuming, because the symptom is oddly specific.
Treating a wildcard as a security upgrade. It puts one private key everywhere it is deployed, which widens the blast radius of any single compromise. That is a trade-off, and for split-trust environments it is often the wrong one.
Buying a wildcard without checking DNS automation. Wildcards require DNS validation. Without an API to create records, every renewal becomes manual work at exactly the moment renewals are getting more frequent.
Tracking certificates instead of hostnames. The list that matters is every name you actually serve over HTTPS. Certificates you know about are a subset, and the forgotten subdomain is the one that expires loudly.
FAQ
Do subdomains need their own SSL certificate?
They need to be covered by a certificate, but not necessarily a separate one. A wildcard certificate covers one level of subdomains at once, and a multi-domain certificate covers a specific named list, so either can cover many subdomains with a single certificate.
**Does a certificate for example.com cover www.example.com?**
Not automatically. They are different hostnames and each must appear in the certificate. Certificate authorities conventionally issue both together, so it usually works in practice, but a certificate listing only the apex will produce a warning on www.
Does a wildcard cover second-level subdomains?
No. A wildcard for *.example.com matches a single label, so it covers api.example.com but not test.api.example.com. Deeper levels need their own wildcard issued for that level.
Is a wildcard certificate less secure than separate certificates?
It concentrates risk rather than being inherently weak. One private key is deployed everywhere the wildcard is used, so a compromise on any of those hosts affects every covered subdomain. Separate certificates limit each incident to one name.
Closing thought
The question sounds like a purchasing decision and is really a naming one. Once you know how your hostnames are structured, how deep they go, whether they share a parent domain, and how often new ones appear, the certificate choice mostly makes itself. What does not make itself is the inventory, which is where the actual outages come from: not the wrong certificate type, but a name nobody remembered was being served.
If you want that inventory maintained without doing it by hand, Odown provides unlimited SSL monitors on every plan including the twelve dollar tier, checks each one on a daily cycle, and alerts at 30, 10, and 7 days before expiry with custom thresholds available. Point one at every hostname you serve rather than every certificate you bought, and the forgotten subdomain stops being the one that surprises you.
