A certificate covers specific names. Which names, and how many, is what separates the three kinds you can buy, and choosing wrong produces either a browser warning or a bill you did not need.
The three shapes
Single-name. Covers one hostname. In practice most issuers include the www form alongside the bare domain, which is what makes it usable at all.
Wildcard. Covers all subdomains at one level of a domain: *.example.com.
Multi-domain (SAN/UCC). Covers a list of names you specify, which can be entirely different domains.
They are not tiers. A wildcard is not "better" than a multi-domain certificate; they cover different shapes of estate.
What a wildcard does not cover
Two limits that surprise people, and both produce a warning instead of a soft failure.
The bare domain. *.example.com matches shop.example.com and does not match example.com. Most issuers add the bare name automatically, check that yours did, because the site that breaks is your main one.
Deeper levels. *.example.com does not match a.b.example.com. A wildcard covers exactly one level, and a second level needs its own wildcard.
When a wildcard earns its place
When subdomains are created regularly and you cannot list them in advance.
A reseller giving each client client.example.com. A platform creating a subdomain per customer. Anything where adding a name means reissuing a certificate you would rather not touch.
Against that: one certificate and one private key covering everything. If that key is exposed, every subdomain is exposed with it, whereas separate certificates limit the damage to one name.
On a server with a handful of stable subdomains, per-name certificates issued automatically are the better arrangement.
When a multi-domain certificate fits
Several distinct domains on one server, and you want one certificate to manage.
The trade is that adding a name means reissuing the certificate and reinstalling it everywhere. On an estate that changes, that becomes a recurring job.
Also worth noting: the list of names is public, because certificates are logged. A multi-domain certificate publishes the fact that these domains are related, which occasionally matters: a client's domain listed alongside their competitor's on your shared certificate is a conversation you would rather not have.
Free automatic certificates change the calculation
Most of the reason to buy a wildcard or a multi-domain certificate was avoiding the work of managing many certificates.
With automatic issuance covering every domain on the server individually, that work is zero. Each name gets its own certificate, each has its own key, and nothing needs reissuing when you add a domain. Managing AutoSSL explains how it decides what to cover.
So the honest position: on a cPanel server, you probably do not need either of these unless you have subdomains that cannot be verified individually.
Wildcards need DNS verification
The practical obstacle to a free wildcard.
A normal certificate is verified over HTTP, by fetching a file from the domain. A wildcard cannot be. There is no single hostname to fetch from, so it requires proving control of the DNS zone by creating a record.
Doing that by hand is not viable on a 90-day renewal cycle. It needs an integration with your DNS provider's API, and if that is not available, per-subdomain certificates are the workable answer. Setting up Let's Encrypt on a VPS sets out the wildcard case specifically.
The names have to match exactly
Browsers compare the requested hostname against the certificate's names, character for character.
So a certificate for example.com alone produces a warning for everyone typing www.example.com, and you will not notice, because you always use one form.
List every name the site answers on: bare domain, www, and any subdomain that serves content. Then test each one instead of the one you use. For checking with openssl, see the SSL troubleshooting guide.
Checking what a certificate actually covers
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"
That prints the full list of names. The Subject Alternative Name field is authoritative. The common name shown in a browser is legacy and is ignored by modern clients.
Do this after any reissue. A certificate that covers fewer names than the previous one is a silent regression, and the first report comes from a visitor.
Renewal is where estates break
A single certificate covering twenty names has one expiry date and one renewal that can fail.
When it does, all twenty sites show a warning at the same moment. Per-name certificates fail one at a time, which is both less dramatic and easier to notice early.
Whichever you use, monitor the expiry from outside the server. A check running on the machine whose certificate expired is not going to tell you. Renewing your certificate explains doing it deliberately.
Choosing, in one paragraph
Stable set of names on a cPanel server: individual automatic certificates. Subdomains created on demand: a wildcard, with DNS API integration. Several unrelated domains you want on one certificate for administrative reasons: multi-domain, accepting the reissue work and the public list of names.
One certificate for many names has one failure
The convenience of covering an estate with a single certificate is also its weakness, and it is worth stating before choosing one.
Every name shares one expiry, so a renewal that fails takes all of them down together rather than one at a time. Every name shares one private key, so a key that is exposed requires reissuing everything.
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \ | openssl x509 -noout -ext subjectAltName | tr ',' '\n' | wc -l
The count tells you how much depends on one renewal. Beyond a certain number, splitting into several certificates by function is worth the extra administration, because it converts a total outage into a partial one.
Every name is visible to everyone
The alternative names list is sent to every visitor and recorded in public logs, which makes it a directory of your infrastructure.
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \ | openssl x509 -noout -ext subjectAltName
Internal names placed on a public certificate are published by doing so. A certificate covering the main site alongside a staging server, an administration panel and an internal tool tells anyone who looks exactly what to try next.
A wildcard avoids this specific problem, since it names the pattern rather than the hosts. That is a genuine argument in its favour on an estate with names you would rather not advertise, and it is separate from the cost argument people usually make.
Adding a name later means reissuing
A multi domain certificate is fixed at issue, and the operational consequence surprises people planning around it.
Adding a name requires a new certificate covering the whole list, which is then installed everywhere the old one was. On several servers that is a coordinated change rather than a small one, and each server that is missed keeps presenting a certificate without the new name.
for h in web1 web2 web3; do printf '%-6s %s\n' "$h" "$(echo | openssl s_client -connect "$h.example.com":443 2>/dev/null | openssl x509 -noout -serial)" done
Comparing serial numbers across servers is the quick check that they are all running the same certificate. Different serials after a reissue means one was missed, and that server will fail at the old expiry date while the others are fine.