SSL Certificates Explained: How Websites Prove They Are Trustworthy

Every time you open a website and see a small padlock next to the address, something quietly important just happened. Before the page even appeared, your browser asked the server a blunt question: “Prove that you really are who you claim to be.” The thing that answers that question is an SSL certificate. Most people never see it, never think about it, and yet it is one of the reasons you can type your password or card number into a site without it being stolen along the way.

In this article we’ll unpack what an SSL certificate actually is, who hands them out, how your browser decides to trust one, and why they expire. No setup steps, no command line — just the ideas, explained slowly enough that they stick.

First, a quick note on the name

You’ll see the term “SSL” everywhere, but it’s slightly out of date. SSL (Secure Sockets Layer) was the original technology for securing web connections. It was replaced years ago by a newer, safer version called TLS (Transport Layer Security). Almost nobody says “TLS certificate” out loud, though — the old name stuck, the way people still say “dialing” a phone number. So when you read “SSL certificate,” “TLS certificate,” or “SSL/TLS certificate,” they all mean the same thing in practice.

If you want a closer look at the encrypted connection itself — the part that actually scrambles your data — that’s a related topic covered here: What Is HTTPS and TLS?. This article focuses on the certificate: the document that makes that secure connection possible in the first place.

So what IS a certificate, really?

Strip away the jargon and a certificate is just a small file. A digital document. It sits on the web server, and when your browser connects, the server hands a copy of it over.

That file does two jobs:

1. It states an identity. “This certificate belongs to the website example.com.” It’s a claim of ownership over a specific domain name.
2. It carries a public key. This is the cryptographic ingredient that lets your browser set up an encrypted, private conversation with the server — so anything you send (passwords, messages, payment details) can’t be read by anyone snooping on the network in between.

Think of it like a passport. A passport is a physical document that says “this person is Jane Doe, a citizen of this country.” You trust it not because Jane printed it herself, but because a trusted authority — the passport office — issued it and stamped it. A homemade passport on nice paper means nothing. The trust comes from who signed it.

A certificate works the same way. Anyone can write a file that says “I am example.com.” What makes a certificate believable is that a trusted authority has digitally signed it.

Enter the Certificate Authority

The “passport office” of the web is called a Certificate Authority, or CA. A CA is an organization whose entire business is verifying identities and issuing signed certificates.

Here’s roughly how it goes when a site owner wants a certificate:

1. Site owner: "I own example.com. I'd like a certificate, please."
2. CA: "Prove it. Do something only the real owner of example.com could do."
3. Site owner completes the challenge (e.g. places a specific file
   on the server, or adds a special DNS record for the domain).
4. CA verifies the challenge succeeded.
5. CA issues a certificate, digitally signed with the CA's own key.

That step 2-to-4 dance is called domain validation. The CA doesn’t take your word for it; it makes you prove control of the domain by doing something only the genuine operator of that domain could do. Once you pass, the CA signs a certificate for you.

That signature is the whole point. The CA is essentially staking its reputation on a statement: “We checked, and the holder of this certificate really does control example.com.”

There are different levels of validation. Most certificates today are Domain Validated (DV), which just confirm control of the domain — fast and automatic. Some businesses pay for Organization Validated (OV) or Extended Validation (EV) certificates, where the CA also verifies the legal company behind the site. For everyday encryption, DV is what the vast majority of sites use.

The chain of trust

This is the part that confuses people, so let’s go slowly.

Your browser does not personally know every CA on Earth, and it certainly doesn’t know example.com. So how does it decide a certificate is legit? Through a chain of trust — a short ladder of signatures, where each link vouches for the next.

Root CA certificate        <- baked into your browser / device
        |  signs
Intermediate CA certificate
        |  signs
example.com's certificate   <- the one the website sends you

At the very top sit a small number of root certificates. These are pre-installed in your operating system and browser by the people who built them. Your device ships with a built-in list of roots it has decided to trust. You didn’t choose them, but they’re there.

A root almost never signs website certificates directly. Instead it signs intermediate certificates, which in turn sign the actual website certificates. When your browser receives example.com’s certificate, it checks the signature, follows the chain upward — example.com signed by an intermediate, the intermediate signed by a root — and asks one question at the top:

“Does this chain end at a root I already trust?”

If yes, the certificate is accepted. If the chain leads nowhere your device recognizes, the browser refuses to trust it and shows a warning. That single check — “can I trace this back to a root I trust?” — is the heart of how the entire web’s identity system works.

What the padlock is actually telling you

When the chain checks out, the certificate matches the domain you typed, and it hasn’t expired, your browser shows the padlock icon. It’s a quiet little signal, but here’s precisely what it claims — and, just as importantly, what it does not claim.

This distinction matters. A padlock confirms two things: your conversation is private, and you’re genuinely connected to the domain in the address bar. It says nothing about whether the people running that domain are trustworthy. A scam site can get a free, valid certificate just as easily as a bank can. So the padlock means “this connection is secure and goes where you think it goes” — not “this site is good.”

Free certificates and where they come from

Years ago, certificates always cost money, which meant a lot of small sites simply skipped encryption. That changed. Today, free, automated certificates are widely available from non-profit and vendor-neutral providers, and most hosting platforms can obtain and install one for you with little or no effort.

A free certificate is not a weaker certificate. The encryption it enables is exactly the same as a paid one. The padlock looks identical. What you generally pay extra for is the higher validation levels (confirming a legal organization, not just the domain), longer support, warranties, or convenience features — not stronger security on the wire.

Because we keep our guidance vendor-neutral here, we won’t single out a brand. The practical takeaway is simply this: there’s no longer any cost reason for a website to run without HTTPS. Free, trusted certificates exist, and they protect visitors just as well.

Why certificates expire (and why that’s good)

Certificates don’t last forever. Each one has a built-in expiry date, and once it passes, browsers stop trusting it — visitors then see a stern warning instead of the page.

It feels inconvenient, but short lifespans are a deliberate safety feature. Here’s the reasoning:

• Limiting damage. If a certificate’s private key is ever stolen, an attacker can impersonate the site only until that certificate expires. A shorter life means a smaller window of harm.
• Forcing fresh validation. Domains change hands. Companies fold. Re-issuing certificates regularly means the proof of ownership stays current instead of resting on a check done years ago.
• Keeping cryptography modern. Regular renewal nudges the whole web toward up-to-date security practices.

The industry has steadily shortened certificate lifetimes over the years for exactly these reasons. The practical consequence is that renewal is not optional — every certificate must be replaced before it lapses.

[ Issued ] -----------------------> [ Expires ]
                                          |
            renew BEFORE this point  -----+
            or visitors get a warning

The good news: because expiry is predictable and frequent, the sensible approach is automation. Most modern setups renew certificates automatically in the background, well before the deadline, so a human never has to remember. A forgotten manual renewal is one of the most common — and most avoidable — causes of a site suddenly throwing security warnings.

Putting the whole picture together

Let’s walk the entire story in one breath, the way it plays out in the half-second before a page loads:

1. You type example.com and hit enter.
2. The server sends its certificate (and the chain above it).
3. Your browser checks: Is the chain signed up to a root I trust?
                        Does the certificate match this exact domain?
                        Is it still within its valid dates?
4. All yes -> browser and server set up an encrypted connection
              using the certificate's public key.
5. Padlock appears. The page loads privately and safely.
6. Any "no" -> warning shown, connection refused or flagged.

Every one of those checks happens automatically, in milliseconds, on every secure visit you make. You never see the machinery. You just see the lock.

Recap

Here are the ideas worth carrying away:

• An SSL/TLS certificate is a small, digitally-signed file that proves a website controls its domain and supplies the public key needed for an encrypted HTTPS connection.
• “SSL” and “TLS” are used interchangeably; TLS is the modern technology, SSL is the old name that stuck.
• A Certificate Authority (CA) issues certificates only after the requester proves control of the domain. The CA’s signature is what makes a certificate believable.
• Browsers trust a certificate by following a chain from the website’s certificate up through an intermediate to a root the device already trusts. No valid chain, no trust.
• The padlock means the connection is encrypted and you’re really talking to that domain — it does not mean the site’s owners are honest.
• Free, vendor-neutral certificates offer the same encryption as paid ones; you mostly pay extra for higher identity validation, not stronger security.
• Certificates expire on purpose to limit damage and keep validation fresh, so automated renewal is essential — a lapsed certificate breaks trust the instant it expires.

Understand those points and the next time you glance at that padlock, you’ll know exactly what it took to put it there.