SSL/TLS Certificates: how do you know who you're talking to?

In our previous story, the Internet Post Office learned to use sealed envelopes. Wonderful! Then one customer asked an awkward question: “How do I know the right person is on the other side of the door?” To find out, we're visiting a hotel where anybody can buy a nice suit. Not everybody should be given the keys to the manager's office.

Five stars, golden handles and a manager from nowhere

A luxurious hotel has opened in the town centre. Marble floors, golden door handles, a giant chandelier. Above the entrance: “THE ROYAL HOTEL”. A guest walks in.

— Hello. I have an appointment with the hotel manager.
— Certainly. That's me.
— How do I know you're the manager?
— Because I'm sitting in the manager's office.
— Any identification?
— I'm wearing a suit!
— A suit isn't identification.
— THEN WHY DID I SPEND THREE THOUSAND ON IT?!

🤣

When using HTTPS, a browser asks a similar question. Before trusting a connection, it wants evidence that the server is authorised to use the website name it is connecting to. A beautiful logo and “trust me” aren't enough.

A TLS certificate: a document tied to a domain name

The security guard holds out his hand.

— Documents, please.
— What documents? I'm the manager!
— Please prove it.
— My name is on the door!
— The toilet door says “Gentlemen”, but that doesn't make everybody inside a hotel manager.

🤣

The networking equivalent is a TLS digital certificate. Among other things, it contains the domain name or names it covers, a public key, a period of validity and information about its issuer. It has a digital signature that helps a browser verify authenticity and detect tampering.

If you're visiting hotel.example, your browser expects a certificate valid for that name. A certificate for restaurant.example isn't enough, even if the same person owns both businesses.

— But I own the restaurant too!
— The documents say restaurant. The guest is visiting the hotel.
— CAN'T YOU ACCEPT THAT IT'S ALMOST THE SAME THING?!
— No. Computers are remarkably unsympathetic to “almost”.

Certificate Authority: who issued that document?

After the first inspection, the manager returns with a new certificate printed on gold paper.

— Here you go. All certified.
— Who issued it?
— I did.
— Excuse me?
— Personally! I even used my official stamp!
— SIR, YOU'VE ISSUED YOUR OWN CERTIFICATE TO YOURSELF!
— Who else was I supposed to ask? The hotel across the street?!

🤣🤣

A self-signed certificate can be technically valid and useful in testing or carefully managed private infrastructure. But an ordinary browser won't trust it automatically just because someone made it look impressive.

On the public Web, certificates are typically issued by a CA (Certificate Authority). The CA performs a defined verification process and signs the certificate. For the common DV (Domain Validation) certificate, the main purpose is to establish control of the domain, not to judge the website owner's character.

— I'd like a certificate for hotel.example.
— Do you control that domain?
— Naturally.
— Please demonstrate that.
— I have business cards!
— Not sufficient.
— A five-star rating?
— Still no.
— A box of chocolates?
— SIR, WE VALIDATE DOMAINS, NOT DESSERT MENUS!

How can you prove that you control a domain?

A certificate authority may ask you to publish a special DNS record, file or response at a specific web address. Imagine an official telling the hotel manager:

— If you really manage this hotel, put up a sign at reception with the number I'll give you.
— Which number?
— 7F2A.
— Could I write “WELCOME, HONOURED INSPECTORS” instead?
— No. It must say 7F2A.
— Government officials have absolutely no imagination.

The popular ACME mechanism, used by services including Let's Encrypt, can automate domain validation, certificate issuance and renewal. Administrators no longer need to keep running to the office with a folder of paperwork.

The chain of trust: an office above another office

The guard studies the new paperwork.

— This certificate was issued by a certificate authority.
— Correct.
— And who vouched for that authority?
— A higher authority.
— Who vouched for the higher one?
— Another one.
— AND WHO VOUCHED FOR THAT ONE?!
— Boss, please stop shouting at the chain of trust!

🤣🤣

A website certificate may be signed by an intermediate CA, whose certificate may in turn be signed by another authority, eventually linking to a trusted root CA. The browser checks signatures, names and other requirements, and ultimately reaches a root certificate that its environment already trusts.

Trust doesn't just appear out of thin air. Browsers or operating systems maintain trusted root certificate stores according to specific rules. There's no infinite queue of officials — the chain ends at an existing trust anchor.

— So the final authority doesn't have to call yet another authority?
— No. It's already in our trusted list.
— WHO WROTE THAT LIST?!
— Boss, please. The guest has been waiting at reception all morning.

Public keys for everyone. Private key? Absolutely not!

The manager has another brilliant idea.

— From today, hand out keys to everybody!
— Public keys?
— ALL THE KEYS!
— We mustn't give away the server's private key.
— WHY NOT?!
— Someone could impersonate your server.
— How would they even find the key?
— You put it on the hotel website. Under “Downloads”.
— ...
— With a note saying “For your convenience”.

🤣🤣🤣

The certificate contains a public key and can be shown to visitors. The matching private key must stay protected by the server operator. During TLS setup, the server can prove that it possesses the appropriate private key, so the client isn't relying on impressive-looking paperwork alone.

Important: in modern TLS 1.3, the certificate key primarily authenticates the server. The client and server establish separate temporary secrets to protect the session, usually using an ephemeral key exchange such as ECDHE. Don't imagine every web page being encrypted directly with the certificate's public key.

The TLS handshake: before we close the door

A new guest approaches reception.

— Hello. I'd like a private conversation.
— Certainly. Here's the hotel's certificate.
— I'll check the name, dates, signatures and issuer.
— Of course.
— Now let's verify the server and agree how to protect the conversation.
— Very good.
— Great. Now we can shut the door and talk.
— Would you care for a coffee?
— No, but could you ask the manager to stop listening through the door?

This is the idea behind a TLS handshake. The parties negotiate security parameters, the client receives and verifies the server certificate, and session keys are established to protect subsequent communication. The details differ between TLS versions, but the principle is simple: verify who you're talking to, establish how to communicate securely, then exchange the actual data.

For ordinary HTTPS, it's usually the server that presents a certificate. There's also mTLS, where the server additionally requests a client certificate — useful in some environments, but not required for every website visit.

SSL or TLS? An old sign on a new building

The guard notices a sign saying “SSL CERTIFICATE”.

— Boss, we're using TLS!
— Then why does the sign say SSL?
— Historical terminology.
— DO WE HAVE TWO SYSTEMS?!
— No. The old SSL protocols are obsolete and shouldn't be used. Modern secure connections use TLS.
— THEN WHY DOES EVERYBODY STILL SAY “SSL CERTIFICATE”?!
— Old names can be unbelievably stubborn.

🤣

SSL (Secure Sockets Layer) was the earlier family of protocols. Modern deployments use TLS (Transport Layer Security), although “SSL certificate” remains a common informal name. An X.509 certificate doesn't become a different document merely because someone uses the older term. Secure configurations should use current TLS versions, not obsolete SSL.

Expiration date: the manager with yesterday's paperwork

One morning, the security guard stops the manager at the entrance.

— Identification!
— I've worked here for ten years!
— Your certificate expired yesterday.
— BUT I'M STILL THE SAME PERSON!
— The document expired.
— THIS IS STILL MY HOTEL!
— The document expired.
— DAMN IT, CAN YOU SAY ANYTHING ELSE?!
— Yes. Please renew your certificate.

🤣🤣

Each certificate has a defined validity period, which browsers check. If it has expired, or isn't valid yet, the browser may display a warning and prevent ordinary access. A badly set clock on a computer can lead to similar confusion.

That's why administrators automate renewal and monitor expiry dates. Issuing a certificate once and forgetting about it forever is not a sensible maintenance plan.

Wrong hotel, unknown issuer or missing paperwork

The guard checks another stack of certificates.

— This certificate is for a different hotel.
— Same owner, though!
— Still a different name.
— What about this one?
— Issued by an authority we don't trust.
— And this one?
— The intermediate certificate is missing.
— HOW MANY FOLDERS HAVE YOU BROUGHT TODAY?!
— Enough to keep Security busy!

Common certificate errors include a hostname mismatch, an expired certificate, an untrusted issuer, an incorrectly configured certificate chain, or a certificate that has been revoked. Browsers may warn about other security issues too.

Revocation is more complicated than checking a date: browsers use different mechanisms and policies for certificate-status checking. Detection isn't always instant or identical across all clients.

One reception, many hotels: SNI

Three hotels share the same entrance. A guest approaches the guard.

— Hello, I'd like the hotel's documents.
— WHICH HOTEL?!
— The one I'm visiting.
— BUT THREE HOTELS USE THIS ADDRESS!
— What if I told you which one I wanted first?
— OH! THAT WOULD HELP A LOT!

SNI (Server Name Indication) lets a client indicate the server name during TLS setup, allowing one IP address to serve different websites with the appropriate certificates. Traditional SNI can expose that hostname to network observers; emerging mechanisms such as ECH aim to reduce this exposure where supported.

A certificate is not a five-star rating or an honesty guarantee

The manager calls a formal press conference.

— GENTLEMEN! WE HAVE A CERTIFICATE!
— Congratulations.
— SO WE HAVE FIVE STARS?!
— No. That's a different assessment.
— SO EVERYBODY KNOWS WE ALWAYS TELL THE TRUTH?!
— No.
— SO A SCAMMER CAN'T HAVE A CERTIFICATE?!
— Also no.
— THEN WHAT DOES THE BLOODY DOCUMENT PROVE?!
— Among other things, that the appropriate public key is associated with the named domain and that its credentials can be checked.
— WHY DOESN'T IT SAY “HONEST MANAGER”, THEN?!
— Because TLS certificates don't certify personality.

🤣🤣🤣

Here's the essential limit: a valid HTTPS certificate does not prove that a website owner is honest. A scammer can obtain a perfectly valid certificate for a domain they control. The browser's lock indicates a secure, authenticated connection to a particular name — not a guarantee about products, statements or intentions.

Certificates can also validate different things: beyond common DV certificates, there are types with additional organisational validation, such as OV and EV. None of them turns into a universal certificate of honesty.

Finale: the manager shows his documents

After days of new procedures, a guest finally checks in.

— Hello, I have an appointment with the manager.
— Here's the certificate for our domain.
— The name matches, the dates are valid, and the signatures and trust chain check out. Excellent.
— So we can start a secure conversation?
— Yes.
— WONDERFUL! — shouts the manager. — EVERYBODY TRUSTS ME NOW!
— No, sir. We trust the verified server identity.
— AND ME?!
— We'll judge that by your customer service.

🤣

The Royal Hotel Management reminds visitors that suits, gold door handles and five-star ratings do not replace TLS certificates. TLS certificates, in turn, do not replace good manners. Negotiations continue over which requirement is harder to fulfil.