Wildcard Certificate Cost: Why Anyone Still Pays Hundreds for Free Encryption

Q: Does a wildcard certificate cover the main domain?

Not by itself. .example.com covers single-label subdomains only, so the apex must be listed separately on the certificate — which is why practical wildcards include both names. It also does not cover nested subdomains, since the wildcard replaces exactly one label.

A commercial wildcard certificate costs between roughly $400 and $1,000 a year depending on validation level and vendor. An automated ACME certificate costs nothing and provides identical encryption, because the encryption was never the thing you were paying for.

The price spread here is one of the strangest in infrastructure — the same cryptographic guarantee at zero and at four figures. The gap is real, and it is not encryption strength. Understanding what the money actually buys makes it obvious which cases justify it, and they are narrower than the sales pages suggest.

What a wildcard certificate is, and its one hard limit
The prices, and what the money buys
The free path, and the DNS-01 requirement
When you should still buy one
How this fits the rest of the stack
FAQ

What a wildcard certificate is, and its one hard limit

A wildcard certificate covers a name with * as the leftmost label: *.example.com secures api.example.com, blog.example.com and any other single-label subdomain.

It has two limits that catch people out.

It covers exactly one level. *.example.com does not cover a.b.example.com, because the wildcard replaces one label, not several. Nested subdomains need their own wildcard at that level.

It does not cover the apex. *.example.com does not secure example.com itself. Every practical certificate therefore lists both — the wildcard and the bare domain — as separate names. If your apex errors while subdomains work, this is why.

Check what a certificate actually covers rather than assuming:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 'Subject Alternative Name'

# Expiry, quickly
echo | openssl s_client -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -dates

The prices, and what the money buys

Roughly, from published vendor pricing:

Domain Validated wildcard — around $400 to $650 a year, with multi-year subscriptions bringing the annual figure down.
Organisation Validated wildcard — around $700 to $1,000, with the higher end at vendors positioned as premium.
Automated ACME wildcard — free, valid ninety days, renewed automatically.

The cryptography is identical across all three. Same algorithms, same key sizes, same TLS handshake, same padlock. What differs:

Validation depth. DV proves control of the domain. OV and EV additionally verify that a real legal entity exists and that you represent it. That verification is human work, and it is most of the cost.
Warranty. A large figure in the marketing — commonly hundreds of thousands of dollars. Read what it covers: it indemnifies the relying party against a mis-issuance by the CA, under conditions that essentially never occur. It is not insurance for you.
Support. A person to talk to when installation goes wrong. Worth something in an organisation without TLS expertise.
Lifetime. Commercial certificates last longer per issuance, which reduces manual work if you are not automating. If you are automating, this is not a benefit.

The uncomfortable summary: for a DV wildcard you are paying several hundred dollars a year for a longer validity period and a support line, because the validation is automated at both ends and the warranty is not for you.

The free path, and the DNS-01 requirement

Wildcards cannot be validated by serving a file over HTTP, because a wildcard is not a specific hostname to visit. They require DNS validation — proving control by publishing a TXT record.

That means your DNS provider needs an API, and your ACME client needs a plugin for it. Most major providers have one.

# Wildcard plus apex, validated via DNS
certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials ~/.secrets/cloudflare.ini \
  -d 'example.com' \
  -d '*.example.com'

# Verify renewal works before you depend on it
certbot renew --dry-run

The dry run is not optional. A renewal that fails silently produces an expired certificate and a site full of browser warnings, and ninety-day certificates give you far less margin than a one-year one.

Two operational details worth building in from the start:

Reload the server after renewal. A renewed certificate on disk that the running process has not reloaded is still the old certificate in memory. Use the ACME client’s deploy hook.
Monitor expiry externally. Do not rely on the renewal job reporting its own failure — a job that is not running cannot tell you it is not running. An external check that alerts at thirty days is the backstop.

The philosophical shift is worth naming. Short-lived automated certificates are more secure in practice than long-lived manual ones, because a compromised key has a much shorter useful life and because renewal that happens every sixty days is renewal that is known to work — unlike an annual process nobody has rehearsed.

When you should still buy one

There are legitimate cases, and they are specific:

You need OV or EV. Some procurement processes, and some regulated industries, require a certificate that names a verified legal entity. Free CAs issue DV only. This is the strongest reason and it is not negotiable when it applies.
Your DNS provider has no API. Wildcards need DNS validation, so an unautomatable DNS provider makes free wildcards impractical. Moving DNS is usually the better fix.
Contractual or compliance requirements naming a specific CA or a warranty figure. Uncommon, and real when it appears.
Devices that cannot run ACME. Some appliances and embedded systems have no automation path, and a ninety-day manual renewal cycle is worse than an annual one.
Support matters more than the money. In an organisation without in-house TLS knowledge, a vendor to call has real value.

And the reasons that do not hold up: stronger encryption (identical), better browser trust (both are trusted equally by every mainstream browser), and the warranty (it does not protect you).

One architectural note. A wildcard means one private key securing every subdomain, so a compromise of that key compromises all of them at once. Where subdomains have different risk profiles — a customer-facing app and an internal admin tool — separate certificates limit the blast radius, and with automation the extra effort is close to zero.

How this fits the rest of the stack

Once certificates are automated, the cost conversation mostly disappears and is replaced by an operational one: is renewal running, does the server reload afterwards, and will anyone find out before expiry if it stops. Those are the questions that actually cause outages.

On RunxBuild that layer is handled. Attaching a custom domain to a static site or a web service issues the certificate and renews it automatically, with no ACME client to maintain, no deploy hook to remember, and no renewal job to monitor. Redirects, rewrites and response headers are dashboard configuration rather than server files. Static sites include 120GB of bandwidth, then $0.10/GB, and services in Node, Next.js, Python, Go, Ruby, Java, .NET or Docker deploy from your GitHub repository with build and runtime logs in one place. To see what a site, a service and a managed database come to, the RunxBuild hosting calculator lists them as separate line items.

Useful related references:

FAQ

How much does a wildcard SSL certificate cost?

Commercial ones run roughly $400 to $650 a year for domain-validated and $700 to $1,000 for organisation-validated, with multi-year subscriptions lowering the annual figure. Automated ACME certificates are free, valid for ninety days, and provide identical encryption.

Is a free wildcard certificate less secure?

No. The cryptography, key sizes and browser trust are identical. What you pay for commercially is deeper validation of your organisation’s identity, a longer validity period, vendor support, and a warranty that indemnifies relying parties against CA mis-issuance rather than protecting you.

Does a wildcard certificate cover the main domain?

Not by itself. *.example.com covers single-label subdomains only, so the apex must be listed separately on the certificate — which is why practical wildcards include both names. It also does not cover nested subdomains, since the wildcard replaces exactly one label.

Why do wildcard certificates need DNS validation?

Because there is no specific hostname to serve a validation file from — the certificate covers a pattern rather than a name. Proving control therefore means publishing a TXT record, which means your DNS provider needs an API and your ACME client needs a plugin for it.

When is a paid wildcard certificate worth it?

When you need organisation or extended validation for procurement or regulatory reasons, when your DNS provider cannot be automated, when a contract names a specific CA, or when devices in the path cannot run an ACME client. Encryption strength and browser trust are not among the reasons.