TLS Cert: What It Proves, What It Does Not, and Why Yours Expired

A TLS certificate proves one thing: that whoever is answering for this domain name also controls the private key a certificate authority vouched for. It does not prove the site is safe, honest, or run by anyone you would trust with money.

That distinction matters more than it sounds. Plenty of people still read the padlock as a trust signal about the business behind the site, and it is nothing of the sort. A phishing site can get a valid certificate in ninety seconds, for free, and it will show the same padlock yours does.

What the certificate genuinely buys you is a private channel and a verified name. Nobody between the browser and your server can read or alter the traffic, and the browser knows it is talking to the host it asked for rather than something that intercepted the connection. That is worth a great deal. It is just not the same as trustworthiness.

What is actually inside the certificate
Domain, organisation and extended validation
The chain is what actually breaks
Why renewals fail, in order of likelihood
The errors you will actually see
What good certificate handling looks like
How this fits the rest of the stack
FAQ

What is actually inside the certificate

Strip away the encoding and a certificate is a short list of claims plus a signature over them.

Subject: the names this certificate is valid for. The one that matters is the Subject Alternative Name list; the old Common Name field is legacy and modern browsers ignore it.
Public key: the half of the key pair the browser will use. The matching private key never leaves your server.
Validity window: not-before and not-after timestamps. Public certificates are now capped at around 13 months, and the industry is moving shorter.
Issuer: which certificate authority signed it.
Signature: the authority’s cryptographic attestation that it checked the subject controls that domain.

You can read all of it against a live host without downloading anything:

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

The servername flag is not optional cosmetics. Without it you are not sending SNI, and a host serving several domains from one address will hand you the wrong certificate and send you off debugging a problem that does not exist.

Domain, organisation and extended validation

Certificate authorities sell three validation levels, and the practical difference between them is much smaller than the price difference suggests.

Domain Validation proves you control the domain. The authority asks you to serve a specific file or publish a specific DNS record; you do; you get a certificate. It is automatable, which is why it is free and why it now covers most of the web.

Organisation Validation adds a check that the company exists. Extended Validation adds a heavier legal check. Both cost real money and take days.

Here is the part the sales pages skip: browsers stopped showing the company name in the address bar years ago. The visible outcome of an extended validation certificate and a free domain validated one is now identical, the same padlock and no name. Unless a compliance requirement or a specific customer contract names organisation or extended validation, you are buying a line item nobody sees. Encryption strength is exactly the same across all three.

The chain is what actually breaks

Browsers do not trust your certificate directly. They trust a small set of root certificates baked into the operating system, those roots sign intermediate certificates, and the intermediates sign yours. The browser needs the whole path.

Your server must send its own certificate plus every intermediate. It must not send the root, because the client already has it. Get this wrong and you produce the most confusing class of TLS bug there is: the site works perfectly in your browser and fails for a colleague, a mobile app, or curl on a CI runner.

The reason is that browsers quietly paper over the mistake. They cache intermediates from previous sites and will fill in a missing one without telling you. A fresh client with an empty cache has no such luxury and fails outright.

Check the chain the way a fresh client sees it:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

You want to see your leaf certificate followed by one or more intermediates, and a final line reading Verify return code: 0 (ok). Anything else is a chain you need to fix, regardless of what your browser shows you.

Why renewals fail, in order of likelihood

Automated renewal is a solved problem, right up until the moment it silently stops working and you find out from a customer. The failure modes are boringly consistent.

The HTTP challenge cannot reach the server. The authority fetches a file under the well-known acme-challenge path. A redirect forcing every HTTP request to HTTPS, an authentication wall, or a firewall rule blocking port 80 will each break it.
The renewal timer is not running. The certificate was issued by hand once, and the job meant to renew it was never enabled. Check with systemctl list-timers.
The certificate renewed but nothing reloaded. New file on disk, old certificate still in the web server memory. The renewal needs a deploy hook that reloads the server.
Rate limits. Repeatedly retrying a failing issuance exhausts the per-domain limit and locks you out for a week. Debug against the staging endpoint, not production.
DNS moved. The domain now points somewhere else, so the challenge validates against a server that is not yours.

Monitor the expiry date from outside your own infrastructure. A check that runs on the same box as the certificate will not alert you when that box is the problem.

The errors you will actually see

Browser TLS errors are written for people who are not you, which makes them harder to act on than they should be. Translated:

ERR_CERT_DATE_INVALID: expired, or the client clock is wrong. Check the server first, then the client time.
ERR_CERT_COMMON_NAME_INVALID: the name being requested is not in the Subject Alternative Name list. Usually the www prefix missing from a certificate issued for the bare domain.
ERR_CERT_AUTHORITY_INVALID: self-signed, or the chain is incomplete. On an internal host this is expected. On a public one it is a missing intermediate.
ERR_SSL_PROTOCOL_ERROR: often not a certificate problem at all. Frequently something is answering plain HTTP on port 443, or a proxy is terminating badly.
SSL_ERROR_RX_RECORD_TOO_LONG: almost always the plain-HTTP-on-the-TLS-port case.

What good certificate handling looks like

The target state is that nobody on the team thinks about certificates at all, and the way you get there is by removing every manual step.

Automated issuance and renewal, with the reload wired into the same hook.
Expiry monitored externally, alerting at 21 days rather than at 2.
Redirect all HTTP to HTTPS, with an exception carved out for the challenge path.
HSTS once you are confident you will never need to go back. Start with a short max-age and raise it.
One certificate covering both the apex and the www host, so a redirect from one to the other does not hit a name mismatch.

On a managed platform this is table stakes rather than a project. Attaching a custom domain to a RunxBuild service provisions and renews the certificate as part of the domain setup, which removes the timer, the reload hook and the expiry alarm from your list in one step.

How this fits the rest of the stack

Certificates are one of those costs that is zero in money and non-zero in attention, and attention is the expensive one. When you are sizing a project it is worth looking at the whole picture, compute and database and storage and bandwidth and the operational work attached to each, rather than only the line items with a price tag. The RunxBuild hosting calculator lays out the paid parts, and the certificate handling comes with the domain rather than as a separate decision.

Useful related references:

FAQ

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

No. SSL was the original protocol and its last version was deprecated in 2015; everything in use today is TLS. The certificate format is identical, and the industry kept saying SSL out of habit. If a vendor sells you an SSL certificate, you are getting a TLS certificate.

Do I need to pay for a TLS certificate?

For almost all public websites, no. A free automated certificate provides identical encryption to a paid one, and browsers display both the same way. Pay only when a compliance requirement or a customer contract specifically names organisation or extended validation.

Why does my site work in Chrome but fail in curl or on mobile?

Almost always an incomplete chain. Your server is not sending the intermediate certificate, and your browser is filling it in from a cache it built visiting other sites. A fresh client has no such cache and fails. Run openssl s_client with the showcerts flag and confirm the intermediates are present.

How long are TLS certificates valid?

Publicly trusted certificates are currently capped at around 13 months, and the maximum lifetime is being reduced over the coming years. Free automated certificates typically issue for 90 days and renew at 60. Shorter lifetimes are the direction of travel, which makes automated renewal effectively mandatory.

What happens if my certificate expires?

Browsers show a full-page interstitial warning and most visitors leave. API clients and mobile apps usually fail the connection outright with no warning at all, so an expiry often surfaces first as a broken integration rather than a broken website. This is why external expiry monitoring matters more than it seems.