JOVANA
Explore Library Glossary Getting Started Three Levels Fields How it works Mission
Join the mission
All guides

Certificates, CAs, and How TLS Builds Trust

You can already encrypt with a key and sign with a private key — but how do you know whose key it is? This guide follows that one nagging question to certificates, certificate authorities, and the handshake that turns a stranger's wire into a private, trusted channel.

The one question public keys cannot answer

In the previous guide you met the two tools that make secure conversation possible. Public-key cryptography gives everyone a public key they can hand out freely and a private key they keep secret, so anyone can encrypt a message that only the private-key holder can read. And a digital signature lets the private-key holder sign something so anyone can check it really came from them and was not altered. Both are genuinely powerful. But they share one quiet, fatal gap.

Here is the gap. Both tools assume you already know whose public key you are holding. Picture connecting to your bank. The bank sends you a public key. You can encrypt to it, you can verify signatures made with the matching private key — but how do you know this key belongs to the bank, and not to an attacker sitting on the wire? Remember the man-in-the-middle attack from guide one: someone in the middle can simply hand you their own public key and claim it is the bank's. You would encrypt your password straight to the attacker. Public-key crypto secures the channel beautifully — to the wrong person.

A certificate is a signed ID card for a key

The fix borrows an idea from everyday life. Your passport is trustworthy not because you printed it, but because a government you both trust vouches for it. A digital certificate is exactly that: an ID card for a public key. It says, in machine-readable form, 'this public key belongs to the name bank.example.com,' plus an expiry date and some other details. And crucially, it carries a digital signature — but not the bank's own signature, because the bank vouching for itself proves nothing. The signature is made by a trusted third party.

That trusted third party is a certificate authority, or CA. A CA is an organization in the business of checking identities and then signing certificates to vouch for them. When the bank wanted a certificate, it proved to the CA that it really controls bank.example.com, handed over its public key, and the CA signed a statement binding the two together. Now the certificate is a signed claim by the CA: 'I, this CA, have verified that this public key belongs to bank.example.com.' The signature means nobody can tamper with the name or the key without breaking it — exactly the integrity property you learned signatures provide.

  CERTIFICATE for bank.example.com
  ---------------------------------
  Subject  : bank.example.com
  Public key : 30 82 01 0a ... (the bank's public key)
  Valid     : 2026-01-01  to  2027-01-01
  Issuer    : Example Trust CA
  ---------------------------------
  Signature : signed by Example Trust CA's private key
              over everything above
A certificate, stripped to its essentials: a name, the public key it claims, an expiry window, who vouched for it, and that voucher's signature over the whole thing.

Why you trust the CA: the chain and the root store

But this only moves the question up a level. To trust the bank's certificate you must trust the CA's signature, which means you need the CA's public key — and how do you trust that one? The honest answer is that the buck has to stop somewhere, and it stops in your own device. Your operating system and browser ship with a built-in list of a few hundred CA public keys that their makers have decided to trust. This list is called the trust store (or root store), and the keys in it are called roots. Those roots are the anchors: you trust them because you trust whoever built your software, and that decision was made before you ever opened a connection.

In practice the bank's certificate is usually not signed directly by a root. Roots are too precious to use day to day, so a root signs an intermediate CA, and the intermediate signs the bank. This forms a chain: bank certificate, signed by intermediate, signed by root. Your software verifies the chain link by link, checking each signature with the public key from the certificate above it, until it reaches a root it already trusts in its store. If every link verifies and the names and dates check out, the chain is trusted; if any link is broken, expired, or ends at a root you do not have, the whole thing is rejected. This layered design is the public-key infrastructure, or PKI — the global system of CAs, certificates, and roots that lets total strangers establish trust.

TLS: putting it all together in one handshake

Now we have all the pieces — public keys, signatures, certificates, and a chain of trust — and we can watch them assemble into the protocol that actually protects your connections. Transport Layer Security, or TLS (its older versions were called SSL, a name that stuck), is the layer that sits on top of TCP and turns a plain, readable byte stream into a private, authenticated one. When your browser shows a padlock and the address starts with HTTPS, that is just HTTP carried inside TLS. TLS begins every connection with a handshake: a short opening conversation that proves identity and agrees on keys before any real data flows.

  1. Your browser opens with a hello: 'I want to talk to bank.example.com securely. Here are the cipher methods I support and a fresh random number.' The server replies with a hello of its own, picking the methods and adding its own random number.
  2. The server sends its certificate (usually the whole chain). Now your browser does the verification you just learned: walk the chain link by link, check each signature, confirm it reaches a trusted root, and confirm the certificate's name really is bank.example.com and has not expired.
  3. Browser and server now perform a key exchange — using the public key from the verified certificate, plus those two random numbers — to agree on a fresh shared secret that no eavesdropper on the wire could compute. From it they derive a symmetric key for this one session.
  4. Both sides switch to that fast symmetric key and exchange a final 'finished' message, each covering everything said so far, so any tampering during the handshake would be caught. From this point on, every byte — your password, the page, all of it — is encrypted and integrity-protected with the session key.

Notice the elegant division of labour, the same one you saw when symmetric and public-key crypto were introduced. The slow public-key tools do the hard, occasional jobs at the start — proving identity through the certificate and bootstrapping a shared secret — and then the connection switches to a fast symmetric key for the bulk of the data. You get the trust of public keys and the speed of symmetric keys, in one motion. This is also why the certificate verification happens before any secret is shared: identity is checked first, precisely so the box you lock is being handed to the right party.

What HTTPS does and does not promise

Once the handshake finishes, that padlock earns you three concrete things and no more. Confidentiality: an eavesdropper sees only ciphertext, so your password and the pages you read are private on the wire. Integrity: nobody can quietly alter the data in flight without detection. And authentication of the server: you really are talking to whoever holds the private key for a certificate that a trusted CA issued for the name in the address bar. Those three map cleanly back to the CIA triad from guide one. It is a lot — but it has sharp edges that are widely misunderstood.

Here is the most important misconception to drop: a valid certificate proves identity, not honesty. It confirms that this really is the site at this name — it says nothing about whether that site is trustworthy, legal, or run by decent people. A scam site can obtain a perfectly valid certificate for its own name and show you a genuine padlock; the lock means 'your connection to this site is private,' never 'this site is safe.' The certificate authenticates the name in the address bar, so the one habit that actually protects you is to read that name carefully. An attacker who registers bank-example-login.com can get a real certificate for it and look just as locked.

A few more honest limits. TLS hides the contents of your traffic, but not entirely the fact of it: an observer can still see which server you connected to and roughly how much data you exchanged. It protects data in transit, but not at rest — once your data arrives at the server, TLS is done, and what happens there is the server's responsibility. And TLS secures one connection; it cannot fix a compromised CA, a phishing link you clicked, or malware already on your machine. Recall from the threats guide that TLS does close the door on passive eavesdropping and on the classic man-in-the-middle who swaps in their own key — that key would not chain to a trusted root, so the handshake fails loudly. TLS is a strong, specific promise. Knowing exactly where it begins and ends is what separates someone who trusts the padlock blindly from someone who reads it correctly.