Last post ended with a promise. We had explained that HTTPS is ordinary HTTP running inside an encrypted tunnel called TLS, Transport Layer Security, and that this tunnel provides confidentiality, integrity, and authentication. But we deliberately left the hardest question unanswered: how does any of that actually work?
It is worth pausing on just how impossible the core problem sounds. Two computers that have never communicated before want to exchange secret information. The only path between them is the open internet, where, as we have seen throughout this series, anyone along the route can read what passes by. And yet, somehow, they need to agree on a secret key that only the two of them know, while an eavesdropper watches every single message they exchange. It sounds like a paradox. If the attacker sees everything, how can the two ends share a secret the attacker does not learn?
And there is a second problem, just as hard. Even if they can agree on a secret, how does your browser know it is talking to the real bank, and not an attacker who has inserted themselves in the middle? Agreeing on a secret with an impostor is worse than useless.
TLS solves both. The first through a beautiful piece of mathematics called public-key cryptography. The second through a system of certificates and authorities that, when you follow it to its root, rests on a surprisingly human foundation of trust. Let us take them in turn.
The Two Problems, Named Clearly
Everything in this post serves two goals. It helps to hold them separate in your mind, because they are genuinely different, and TLS uses different tools for each.
Confidentiality: agree on a secret key over a channel where everything is visible, so that all further communication can be encrypted with it. This is the key-exchange problem.
Authentication: prove that the server is genuinely who it claims to be, so you are not establishing that secret with an impostor. This is the certificate problem.
A connection that has confidentiality but not authentication is encrypted, but you might be talking privately to a criminal. A connection with authentication but not confidentiality proves who you are talking to, but everyone can hear it. You need both, and TLS delivers both in a single handshake. First, the mathematics that makes confidentiality possible.
The Impossible-Sounding Trick: Public-Key Cryptography
For most of history, encryption worked one way: the same secret key both locked and unlocked a message. This is called symmetric encryption, and it is fast and effective, but it has a fatal flaw for our problem. Both parties need the same key, and if they have never met, how do they agree on that key without sending it across the open network where an eavesdropper would simply catch it in transit? You cannot secure the channel by sending the key over the unsecured channel.
The breakthrough that solves this is asymmetric, or public-key, cryptography, and it is one of the most important ideas in all of computing. Instead of one shared key, each party has a pair of keys that are mathematically linked: a public key and a private key. The public key can be shared with the entire world. The private key is kept absolutely secret, never shared with anyone.
The magic is in how they relate. Anything locked with the public key can only be unlocked with the matching private key, and nothing else, not even the public key that locked it. Picture a padlock that anyone can snap shut, but that only one unique key can open. You can hand out open padlocks to the whole world, invite anyone to lock a message and send it to you, and rest assured that only you, holding the single private key, can open any of them. The eavesdropper can watch a locked message travel past and is powerless to open it, even though they watched it being locked, and even though they have a copy of the very padlock that locked it.
This is what makes the impossible possible. Two strangers can now establish a shared secret in full view of an eavesdropper. There are a couple of ways to use this, and modern TLS uses an elegant one, but the essential point is this: public-key cryptography lets you bootstrap a secret over an open channel, because the piece that unlocks is never transmitted at all. It stays on the private side the whole time.
There is one catch, and it shapes everything that follows. Public-key cryptography is mathematically expensive and slow. It would be far too costly to encrypt an entire web session, every request and response, this way. So TLS uses it for exactly one job: the delicate task of agreeing on a secret at the start. Once both sides share that secret, they switch to fast symmetric encryption for the actual data. Public-key crypto is the armoured van that delivers the key. Symmetric encryption is the fast, efficient lock used for everything afterwards. You get the security of public-key infrastructure and the speed of symmetric encryption, together.
The TLS Handshake, Step by Step
Now we can watch the whole thing happen. When your browser connects to an HTTPS site, before any web page data flows, the two sides perform the TLS handshake. I will describe it as modern TLS, version 1.3, does it, because that is the current standard and the cleanest version of the story.
Step 1, Client Hello. Your browser opens by saying hello. It sends the TLS version it wants to use, a list of encryption methods (cipher suites) it supports, and a random number. Crucially, in modern TLS it also immediately generates a temporary key pair for this connection and sends its share of the key-exchange material right away, to save a round trip.
Step 2, Server Hello, and the Certificate. The server responds. It picks the encryption method both sides will use, sends its own random number and its own share of the key-exchange material, and, critically, sends its certificate. That certificate contains the server's public key and its claimed identity, the domain it says it is. We will scrutinise this certificate in a moment, because it is the entire basis of authentication.
Step 3, the shared secret is derived. Here is the elegant part. Using the key-exchange material both sides have now exchanged, each end independently performs a calculation that produces the same shared secret, without that secret ever being sent across the wire. Both sides arrive at the same key by combining their own private piece with the other side's public piece. An eavesdropper who saw both public pieces cannot reproduce the result, because they never had either private piece. This is the modern Diffie-Hellman key exchange, and it has a valuable property called forward secrecy: because the key pair for this connection is temporary and thrown away afterwards, even if the server's long-term private key is stolen in the future, past recorded conversations still cannot be decrypted. The keys that protected them no longer exist anywhere.
Step 4, proving identity. Deriving a shared secret is not enough, because you might have derived it with an impostor. So the server now proves it genuinely owns the certificate it sent. It does this by signing a hash of the handshake so far with its private key. Your browser uses the public key from the certificate to verify that signature. Only the true owner of the certificate's private key could have produced a signature that verifies against its public key, so this step proves the server on the other end is the legitimate holder of the certificate, not someone merely replaying a copy of it.
Step 5, encrypted communication begins. Both sides confirm the handshake is intact with a finished message, and from this point on, everything, every HTTP request and response from the last post, is encrypted with the fast symmetric key derived from the shared secret. The tunnel is open.
All of this happens in a few milliseconds, before the first byte of the actual page is sent. Every single time you visit an HTTPS site, this exchange plays out invisibly.
But notice that the entire authentication step rests on one assumption we have not yet justified: that the certificate can be trusted. Your browser verified that the server owns the certificate. But what makes the certificate itself believable? Anyone can generate a key pair and claim to be your bank. This is the second great problem, and it is where certificates and authorities come in.
The Certificate: A Public Key With an Identity Attached
Let us be precise about what a certificate actually is, because it is the linchpin of the entire system.
On its own, a public key is anonymous. It is just a number. If a server hands your browser a public key and says "I am your-bank.com," nothing about the key itself proves that claim. An attacker could generate their own key pair and make the identical claim. A public key proves you can talk to whoever holds the matching private key. It says nothing about who that holder actually is.
A certificate solves this by binding a public key to an identity, and having that binding vouched for by a trusted third party. A certificate essentially says: "This public key belongs to this domain, and I, a certificate authority, have verified that and put my name to it." It contains the public key, the identity (the domain name), an expiry date, and, crucially, a digital signature from the authority that issued it.
That signature is the key to everything. It is created using the same public-key mathematics, in reverse. The certificate authority signs the certificate with its own private key. Anyone can then verify that signature using the authority's public key, and a valid signature proves that this authority really did issue and vouch for this certificate, and that it has not been tampered with since. So the question of "can I trust this public key belongs to this domain" becomes "do I trust the authority that signed this certificate." Which raises the obvious next question: why would you trust that authority?
The Chain of Trust: Why Your Browser Trusts Anyone at All
This is the deepest question in the whole system, and answering it reveals the surprisingly human foundation underneath all of internet security.
Certificates are not signed in a flat, single layer. They form a chain of trust, a hierarchy with three levels.
At the bottom is the end-entity certificate, the one for the actual website, your-bank.com. It was issued and signed by an intermediate authority.
In the middle sits one or more intermediate certificate authorities. These do the day-to-day work of issuing certificates to websites. Each intermediate's own certificate is, in turn, signed by an authority above it.
At the top sits a root certificate authority. The root is the ultimate anchor. Its certificate is special in two ways: it is self-signed, meaning it vouches for itself, and, most importantly, it is pre-installed in a trust store that ships with your operating system and browser. When you installed your OS or browser, it came with a built-in list of a few hundred root authorities that its makers have decided to trust.
Now the chain makes sense. When your browser receives the website's certificate, it checks the signature and sees it was signed by an intermediate. It checks the intermediate's certificate and sees it was signed by a root. It checks whether that root is in its pre-installed trust store. If the chain leads, link by verified link, up to a root the browser already trusts, the certificate is accepted. If it leads nowhere, or to an unknown root, the browser shows the security warning you have occasionally seen.
So the honest answer to "why does your browser trust anyone" is this: it trusts a website's certificate because it chains up to a root authority that was placed in your device's trust store by the company that made your browser or operating system. The entire edifice of web encryption rests, at its foundation, on a curated list of a few hundred organisations that browser and OS makers have vetted and chosen to trust on your behalf. Trust on the internet is not magic. It is a pre-agreed list, shipped to you inside your software.
Why the layered structure, rather than roots signing website certificates directly? Because it isolates the most precious keys. The root's private key is so catastrophically important that it is kept offline, in physical vaults, used as rarely as possible. The intermediates do the daily work and absorb the daily risk. If an intermediate is compromised, it can be revoked without destroying the root and every certificate beneath it. The hierarchy exists to protect the anchor and to contain damage. Which brings us, inevitably, to what happens when this system fails.
When Trust Breaks: The Structural Weakness at the Heart of HTTPS
Everything above describes the system working. But the series' commitment to honesty demands we look at how it breaks, because the trust model has a genuine structural weakness, and it has failed in the real world with serious consequences.
Here is the weakness, stated plainly. Your browser trusts several hundred root authorities equally. For any given website, it will accept a valid certificate signed by any one of them. This means that every single certificate authority in that trust store is a potential single point of failure for the entire web. If any one of those hundreds of authorities is compromised or misbehaves, an attacker can obtain a fraudulent-but-valid certificate for any domain they like, your bank, your email, anything, and your browser will accept it without complaint. The security of HTTPS is, in a real sense, only as strong as the weakest authority in the list.
This is not theoretical. In 2011, a Dutch certificate authority called DigiNotar was compromised by an attacker. Because DigiNotar was a trusted root, the attacker was able to issue fraudulent but fully valid certificates for high-value domains, including Google. Those forged certificates were then used to intercept the encrypted Gmail traffic of an estimated hundreds of thousands of users in Iran, reading communications that the victims believed were completely secure. The padlock was there. The encryption worked perfectly. And it was all being delivered, sealed and trusted, straight to an attacker, because the authority underpinning the trust had been breached.
The response was swift and brutal, and it shows how the system defends itself. Once the compromise was understood, browser and operating system makers removed DigiNotar from their trust stores entirely, within days. Every certificate DigiNotar had ever issued instantly became untrusted worldwide. The company, its authority gone, went bankrupt within weeks. This is the ultimate enforcement mechanism: an authority that fails badly enough is simply deleted from the lists, and ceases to exist.
DigiNotar was not unique. There have been other cases, authorities that mistakenly issued powerful intermediate certificates, or were tricked into issuing certificates for domains the requester did not own. Each incident exposed the same underlying truth: the convenience of trusting many authorities is also the fragility of trusting many authorities.
The system has been hardened in response, and it is worth knowing how, because it connects to the theme of layered defence this series keeps returning to. A major improvement is Certificate Transparency: certificate authorities are now required to publish every certificate they issue to public, append-only logs. This means that if an authority issues a certificate for your-bank.com, the real owners of that domain can see it appear in the logs and raise the alarm, even if they never requested it. It does not prevent mis-issuance, but it makes it visible and detectable, turning a silent betrayal into a public record. Combined with certificate revocation mechanisms and the ever-present threat of removal from trust stores, it keeps the authorities honest through accountability rather than through perfect prevention.
And so we arrive, as the series so often does, at the honest conclusion. The trust that secures the entire web is not absolute or mathematical at its foundation. It is institutional. It rests on a curated list of organisations, kept honest by transparency, revocation, and the credible threat of instant excommunication. It works remarkably well. But it is a human system with human failure modes, and understanding that is far more valuable than believing the padlock represents some unbreakable mathematical guarantee. It does not. It represents a well-designed, well-defended, but ultimately human chain of trust.
This also completes the honest point from the last post. The padlock proves your connection is encrypted and that the server holds a certificate for the domain, vouched for by a trusted authority. That is a real and valuable guarantee. But it is a statement about domain control and a chain of institutional trust, not a statement that the site is honest, and not an unbreakable one. Now you know exactly what stands behind it, and exactly where it can bend.
Commands to See It Yourself
The entire certificate system is open to inspection, and looking at a real certificate makes all of this concrete.
See a website's full certificate and chain:
openssl s_client -connect example.com:443 -showcerts
This connects and prints the certificates the server presents, the end-entity certificate and the intermediates, the actual chain we discussed, as raw data.
See a certificate's details in readable form:
openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -text
This decodes the certificate into human-readable fields. Look for the Issuer (the authority that signed it), the Subject (the domain it is for), the Validity dates, and the Public Key. You are reading the exact binding of key to identity that this whole post described.
See just the issuer and validity, quickly:
openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -issuer -subject -dates
In your browser: click the padlock icon in the address bar and select the certificate or connection details. Your browser will show you the full chain, from the site's certificate up through the intermediate to the trusted root, exactly the links your browser verified to decide the connection was safe. You can see, for any site, precisely which authority vouched for it and which root anchors the trust.
What You Now Understand
You came in with two questions that sounded impossible, and you can now answer both.
How do two strangers agree on a secret over an open channel? Through public-key cryptography: a mathematically linked pair of keys where the public one locks and only the private one unlocks, so a shared secret can be established in full view of an eavesdropper who never sees the piece that unlocks. Because that mathematics is slow, TLS uses it only to bootstrap a fast symmetric key, and modern TLS does so with forward secrecy, so that stealing a key tomorrow cannot unlock the conversations of today. You can trace the whole handshake: hello, certificate, key exchange, identity proof by signature, and then the encrypted tunnel.
And how does your browser know the server is genuine? Through certificates, which bind a public key to an identity and carry the signature of a certificate authority. That authority's certificate is signed by another above it, forming a chain that leads up to a root authority pre-installed in your device's trust store. Your browser trusts a site because the chain climbs, link by verified link, to a root it was told to trust when you installed your software.
Most importantly, you understand the honest truth at the foundation. That trust is institutional, not magical. It rests on a few hundred authorities, any one of which is a potential single point of failure, as the DigiNotar breach showed when forged certificates were used to spy on real people behind a perfect padlock. The system defends itself not through perfect prevention but through transparency, revocation, and the credible threat of instant removal from the trust stores. It is a human chain of trust, well-designed and well-defended, and now you can see every link in it.
In the next post, we step back from the web and look at how traffic actually crosses the entire internet, from one network to another, all the way around the world. We will meet the routers and the routing protocols that stitch tens of thousands of independent networks into one, and we will see why the system that decides how your data traverses the globe was also, like so much of the internet, built on trust, with consequences we have already glimpsed. That is Post 9, on routing and BGP.
This is Post 8 of the Networking Foundations series. If TLS and certificates finally make sense, and you can see both the beauty of the cryptography and the humanity of the trust beneath it, share it with someone who thinks the padlock is pure mathematics. New here? Start with Post 1, and Post 7 on HTTP and HTTPS leads directly into this one. Subscribe to our newsletter to get each new post as it publishes.
Top comments (0)