Unlimited SSL: What That Phrase Is Actually Selling

Q: What is the difference between a wildcard and a multi-domain certificate?

A wildcard covers every subdomain at one level, so .example.com matches shop and blog but not deep.shop.example.com. A SAN or multi-domain certificate lists specific hostnames explicitly. Use a wildcard when subdomains are created dynamically and cannot be enumerated; it requires DNS-based validation and therefore a DNS provider with an API.

TLS certificates have been free and automated since ACME became widespread. So unlimited SSL on a hosting plan means only that the host will not charge you per hostname for something that costs them nothing. It is the absence of an artificial fee, not a feature.

This phrase appears on hosting comparison tables as though it were a differentiator, alongside genuine ones like storage and bandwidth. It made sense when a certificate was a purchase from a commercial authority with a per-domain price. That world ended some years ago, and what is worth comparing now is entirely different.

Why certificates became free
What actually differs between certificates
What to actually evaluate
Rate limits, which are the real limit
Getting the configuration right
What to make of a plan advertising it
How this fits the rest of the stack
FAQ

Why certificates became free

Certificates used to be sold. You generated a signing request, paid a certificate authority, went through a validation process, and received a file valid for a year or more. Each hostname meant another purchase, so hosts charging per SSL certificate were passing on a real cost.

Let’s Encrypt changed that by offering free domain-validated certificates issued through an automated protocol called ACME. Your server proves control of the domain — by serving a specific file or publishing a DNS record — and receives a certificate without a human involved.

Because it is automated, the certificates are short-lived: ninety days rather than a year. That sounds like a burden and is the opposite, because it forces automatic renewal, and automatic renewal is the only kind that reliably happens. The industry has been moving toward shorter lifetimes generally for the same reason.

Other authorities offer free ACME certificates too, and every serious platform, control panel, and web server now supports the protocol. Certificates being free is settled and universal.

So a host advertising unlimited SSL is telling you they do not charge extra for it, which is table stakes. A host that does charge per certificate is worth noticing — for what it says about the rest of their pricing.

What actually differs between certificates

Two distinctions matter and one does not.

Single-name, SAN, or wildcard. A single-name certificate covers one hostname. A SAN certificate lists several explicitly — example.com, www.example.com, shop.example.com. A wildcard covers every subdomain at one level, so *.example.com matches shop, blog, and api but not deep.shop.example.com.

The practical rule: a SAN certificate listing the hostnames you actually use is fine and is what most platforms issue automatically. A wildcard is worth having when subdomains are created dynamically — one per customer, one per branch — because you cannot enumerate them in advance. Wildcards require DNS-based validation, which means your DNS provider needs an API the ACME client can use.

Validation level. Domain validation proves you control the domain. Organisation and extended validation additionally verify the legal entity, with a manual process and a real price.

This is the distinction that does not matter any more. Browsers removed the visual treatment that once distinguished extended validation — the green bar with the company name — because research showed users did not notice or understand it. A modern browser shows the same padlock for a free DV certificate and an expensive EV one. Unless a specific contract or compliance regime requires OV or EV, there is no user-visible benefit to paying for it.

The encryption is identical in all cases. The certificate proves identity; it does not make the connection stronger.

What to actually evaluate

Given that certificates are free, here is what separates good handling from bad.

Automatic renewal. Certificates last ninety days. If renewal is manual, the site will eventually go down with a browser warning that stops visitors dead. Automatic renewal is the entire game.
Renewal monitoring. Automation fails — a validation path breaks, a DNS record changes, a rate limit is hit. Something should tell you before expiry, not after.
Coverage of every hostname. A certificate for example.com does not cover www.example.com. Both must be listed, and visitors will type both.
Speed of issuance for a new domain. Adding a custom domain should produce a working certificate in minutes, not require a support ticket.
Wildcard support if you need it, which requires DNS API access.
Redirect handling. HTTP should redirect to HTTPS automatically, in one hop.
HSTS support, so browsers refuse to connect over plain HTTP after the first visit.

Renewal is the one to weigh most heavily. Expired certificates are one of the most common causes of a site being effectively down, and they happen to organisations of every size, invariably because a renewal that someone was supposed to do was not done.

On RunxBuild, certificates for custom domains are issued and renewed as part of the project configuration — adding a domain produces a certificate, and the renewal is not something anyone has to remember.

Rate limits, which are the real limit

If unlimited SSL has any literal meaning, it is here, and the constraint is not the host’s pricing but the certificate authority’s rate limits.

Let’s Encrypt limits how many certificates can be issued per registered domain in a rolling window, how many duplicate certificates you can request, and how many failed validations you may accumulate before being temporarily blocked.

For an ordinary site these are irrelevant — you will never come close. They become real in specific situations: a platform issuing certificates on behalf of many customer subdomains, a misconfigured renewal loop requesting the same certificate repeatedly, or a testing script pointed at the production endpoint rather than the staging one.

That third case is the common self-inflicted one. Use the staging environment while developing anything that requests certificates, then switch to production once it works. A rate limit triggered by a test loop can lock you out for a week.

If you genuinely need certificates for a large number of hostnames, a wildcard covers all subdomains at a level with one certificate and one renewal, which sidesteps the per-name limits entirely.

Getting the configuration right

A certificate that exists is not the same as TLS configured well. A few things worth checking once.

The full chain must be served. A certificate served without its intermediate certificates validates in some browsers and fails in others, which produces the maddening bug where it works on your machine and not on a colleague’s phone. Test with an external checker rather than your own browser, which may have cached the intermediate.

Redirect HTTP to HTTPS with a 301, in one hop. A chain of redirects to reach the secure canonical URL costs a round trip per hop on every first visit.

Enable HSTS once you are confident the site works entirely over HTTPS. It instructs browsers never to attempt plain HTTP for your domain. Start with a short max-age, and be aware that a long max-age is difficult to undo — browsers honour it for the stated duration regardless of what you do afterwards.

Disable old protocol versions. TLS 1.2 and 1.3 are current; anything earlier should be off, and most platforms handle this for you.

Check for mixed content. A page served over HTTPS that loads an image or a script over HTTP triggers a browser warning or has the resource blocked entirely. After moving a site to HTTPS this is the most common remaining problem, and it usually comes from hardcoded absolute URLs in content.

# Inspect the served certificate and its chain
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer

What to make of a plan advertising it

When a hosting comparison lists unlimited SSL as a feature, treat it as a signal rather than a benefit.

It tells you the host is not charging for something free, which is the minimum. It tells you nothing about whether renewal is automatic, whether a new domain gets a certificate in minutes or after a support ticket, or whether the intermediate chain is served correctly.

The questions worth asking instead: is renewal automatic and monitored, does adding a custom domain issue a certificate without intervention, are wildcards available if I need them, and does HTTP redirect to HTTPS by default?

A host that answers those well is worth more than one advertising an unlimited quantity of something that has no unit cost.

And if you ever encounter a host charging per certificate in 2026, that is worth treating as information about their pricing generally rather than as a line to negotiate.

How this fits the rest of the stack

Certificates are free and automated, so unlimited SSL is the absence of a fee rather than a feature. What separates good from bad is whether renewal happens without anyone remembering, whether every hostname a visitor might type is covered, and whether the chain is served correctly. Custom domains and certificates on RunxBuild are handled at the project level with renewal built in, and the RunxBuild hosting calculator covers the parts that do have a unit cost — the service, the database, and the bandwidth.

Useful related references:

FAQ

Is SSL free now?

Yes. Let’s Encrypt and other authorities issue free domain-validated certificates through the automated ACME protocol, and every serious platform and web server supports it. A host advertising free or unlimited SSL is describing the absence of an artificial fee rather than a feature they built.

What is the difference between a wildcard and a multi-domain certificate?

A wildcard covers every subdomain at one level, so *.example.com matches shop and blog but not deep.shop.example.com. A SAN or multi-domain certificate lists specific hostnames explicitly. Use a wildcard when subdomains are created dynamically and cannot be enumerated; it requires DNS-based validation and therefore a DNS provider with an API.

Do I need to pay for an EV certificate?

Almost certainly not. Browsers removed the visual treatment that once distinguished extended validation, so a paid EV certificate and a free domain-validated one show the same padlock. The encryption is identical either way. Pay for OV or EV only if a specific contract or compliance regime requires it.

Why do Let’s Encrypt certificates expire after 90 days?

Short lifetimes force automatic renewal, and automatic renewal is the only kind that reliably happens. A certificate valid for a year is a task someone will forget in eleven months. The industry is moving toward shorter lifetimes generally for the same reason, so automation is now a requirement rather than a convenience.

My certificate works in one browser but not another. Why?

Almost always a missing intermediate certificate. Some browsers can fetch or cache the intermediate and others cannot, so the same site validates in one and fails in another. Serve the full chain rather than just the leaf certificate, and test with an external checker rather than your own browser, which may have the intermediate cached.