Secure Socket Layer Certificate: What You Are Actually Buying

An SSL certificate is a file that binds a domain name to a public key, signed by an authority browsers already trust. Two things are worth knowing before you buy one: SSL has been obsolete since 2015 and what you are using is TLS, and a free certificate provides exactly the same encryption as an expensive one.

The name stuck because it was in everyone’s documentation, product pages, and vocabulary. That is harmless. What is not harmless is the assumption that price correlates with security, because it does not — the difference between a free certificate and a several-hundred-pound one is what the authority checked before issuing it, not how strong the resulting encryption is.

Table of contents

• SSL, TLS, and why the name persists
• What the certificate actually does
• The three validation levels
• Certificate types by coverage
• Renewal is the part that actually breaks
• Checking what you are serving
• How this fits the rest of the stack
• FAQ

SSL, TLS, and why the name persists

The history, briefly, because it explains the naming mess:

• SSL 2.0 and 3.0 shipped in the mid-nineties and are both broken. SSL 3.0 was formally deprecated in 2015 after the POODLE attack.
• TLS 1.0 replaced SSL 3.0 in 1999. It and TLS 1.1 were deprecated in 2021.
• TLS 1.2 and TLS 1.3 are what is actually in use. TLS 1.3 is faster, with a one-round-trip handshake and the weak cipher options removed.

So nothing you deploy today runs SSL. Certificates are called SSL certificates for the same reason people say they are dialling a phone number — the term outlived the mechanism.

This is not pedantry when it comes to configuration. A server configured to accept SSL 3.0 or TLS 1.0 for compatibility is measurably less secure, and both fail modern security scans. TLS 1.2 as a minimum, with 1.3 preferred, is the current baseline.

What the certificate actually does

The certificate solves identity, not encryption. Encryption without identity is useless — you would have an encrypted connection to whoever intercepted you.

The chain works like this:

1. Your browser ships with a store of root certificates from authorities it trusts.
2. Your server presents a certificate saying it holds the private key for example.com, signed by an intermediate authority.
3. That intermediate is signed by a root in the browser’s store.
4. The browser verifies the chain, checks the domain matches and the certificate has not expired, and then negotiates encryption keys.

Everything after step 4 — the actual encryption — is identical regardless of what the certificate cost. The cipher suites are negotiated between browser and server, and the certificate has no bearing on their strength.

This is the fact that makes certificate pricing confusing. You are buying a signature from an organisation browsers trust, and the amount of verification behind that signature.

The three validation levels

What actually differs between certificates:

• Domain Validation (DV) — the authority confirms you control the domain, usually by having you serve a file or add a DNS record. Automated, issued in seconds, free. Proves control of the domain and nothing else.
• Organisation Validation (OV) — the authority additionally verifies your organisation exists as a legal entity. Takes days, costs money, and the organisation name appears in the certificate details, which essentially nobody looks at.
• Extended Validation (EV) — a more thorough legal and physical verification. Used to produce the green address bar with the company name in it.

The EV case collapsed. Browsers removed the special interface treatment between 2018 and 2019, after research showed users did not notice it and did not behave differently when it was absent. Without the visual distinction, EV is a more expensive certificate that looks identical to a free one in the browser.

For the overwhelming majority of sites, DV is the correct choice. OV and EV make sense mainly where a compliance requirement or a procurement checklist demands them — which is a real reason, just not a security one.

Certificate types by coverage

The other axis is how many hostnames a certificate covers:

• Single domain — one hostname. A certificate for example.com typically also covers www.example.com, and nothing else.
• Wildcard — *.example.com, covering every subdomain at exactly one level. Not api.staging.example.com.
• Multi-domain (SAN) — an explicit list of unrelated hostnames on one certificate.

Wildcards used to be the practical choice because issuing one certificate was much less work than issuing thirty. With automated issuance that argument is weaker, and per-hostname certificates have a real advantage: a compromised private key affects one host rather than every subdomain.

Wildcards still earn their place when hostnames are created dynamically — a platform giving each customer a subdomain cannot issue certificates for names that do not exist yet.

Renewal is the part that actually breaks

Certificate expiry is the most common TLS failure in production, and it is entirely self-inflicted. Public certificates have been capped at 398 days for years, and the industry is moving toward much shorter lifetimes — which makes manual renewal untenable rather than merely annoying.

The failure mode is bad. An expired certificate produces a full-page browser interstitial warning users the site may be malicious. It does not degrade gracefully; the site is effectively down for anyone who respects the warning.

The fix is automation, not diligence. ACME clients handle issuance and renewal on a schedule, typically renewing at a third of the lifetime remaining so a transient failure has weeks of retry room.

Two things worth having regardless of how renewal happens:

1. External expiry monitoring. Something that checks the certificate your server is actually serving, from outside your network. Renewal succeeding is not the same as the new certificate being loaded — a renewed certificate that the web server never reloaded is a classic outage.
2. An alert with enough lead time. Two weeks, not two days.

Checking what you are serving

To see the certificate a server is actually presenting, including dates and the chain:

openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

The -servername flag matters. Without it, openssl does not send SNI and a server hosting several sites returns its default certificate rather than yours, which produces a mismatch that looks like a bug and is not.

The most common real problem this surfaces is an incomplete chain: your certificate is valid but the intermediate is missing. Desktop browsers often paper over this by fetching the intermediate themselves, while mobile clients and command-line tools fail outright. The result is a site that works for you and not for a meaningful share of your users.

That asymmetry is worth remembering. Testing TLS only in your own browser hides exactly the failures that matter most, because your browser is the most forgiving client you have.

How this fits the rest of the stack

The practical summary is that certificates are a solved problem when issuance and renewal are automatic, and a recurring outage risk when they are not — and the difference has nothing to do with what you paid. Custom domains and certificates on RunxBuild covers attaching a hostname and having the certificate issued and renewed as part of the platform rather than as a calendar reminder. When you are working out what a site with a custom domain, an API, and a database costs together, the RunxBuild hosting calculator shows them as separate line items.

Useful related references:

• DNS Probe Finished Bad Config: Diagnose the Broken Layer
• Docker Socket Permission Denied: Fix Access Without chmod 666
• Secure Cloud Computing: Defaults That Hold Up Under Audit
• Services on RunxBuild

FAQ

Is there a difference between an SSL and a TLS certificate?

No — they are the same file. SSL was replaced by TLS in 1999 and every current connection uses TLS 1.2 or 1.3. The certificate is called an SSL certificate purely out of habit.

Is a free SSL certificate less secure than a paid one?

No. The encryption is negotiated between browser and server and is identical either way. What you pay for is the level of verification the authority performed before signing, not stronger cryptography.

What is the difference between DV, OV, and EV certificates?

DV proves you control the domain and is automated and free. OV additionally verifies your organisation legally exists. EV involves deeper verification but browsers removed the special address bar treatment it used to earn, so it is now visually indistinguishable.

Does a wildcard certificate cover all subdomains?

Only one level. A certificate for *.example.com covers api.example.com but not api.staging.example.com, which needs its own wildcard for *.staging.example.com.

Why does my site work in my browser but fail elsewhere?

Usually an incomplete certificate chain. Desktop browsers often fetch the missing intermediate themselves, while mobile clients and command-line tools fail outright. Check the chain with openssl s_client rather than trusting your own browser.