Rebuilding TLS, Part 4 - Certificates and Trust

How certificates close the man-in-the-middle gap

Previous Article:

Rebuilding TLS, Part 3 — Building Our First Handshake

A secure connection to the wrong server is still a broken connection.

That sentence looks strange at first. If traffic is encrypted, if nobody can read it, if nobody can modify it, then what is still missing?

The missing piece is identity.

In the previous parts of this series, we slowly moved from a plain TCP connection to something that started to look like a real secure channel. First, we added encryption. Then we added integrity. Then we stopped using fixed shared keys and introduced a handshake with X25519 and HKDF, so the client and server could derive fresh session keys for every connection.

That was a big step forward, but it was still not enough.

The client could now create a strong encrypted channel, but it still had no reliable way to know who it had created that channel with. It could be the real server. It could also be an attacker sitting in the middle, performing a separate key exchange with the client and another one with the real server.

In this post we will discuss why key exchange is not the same as authentication, why certificates exist, how certificate chains work, and how I added a simplified certificate-based authentication layer to my small TLS-like protocol.

By the end, the protocol will finally move from:

“I have an encrypted channel with whoever answered.”

to:

“I have an encrypted channel with the server that proved its identity.”

That is the moment where this toy protocol starts to feel much closer to real TLS.

The Problem We Still Had After Key Exchange

At the end of Part 3, the protocol already had a real handshake.

The client and server exchanged ephemeral X25519 public keys. They used the resulting shared secret as input to HKDF. From that, they derived separate keys for client-to-server and server-to-client traffic. Then they used those keys to protect application data with AES-GCM.

That is already much better than hardcoding a shared key into both programs.

A hardcoded key has many problems. If someone gets it once, every connection using that key is compromised. If you want to rotate it, you need to update both sides. If two clients use the same key, one compromised client can affect other connections. It is simple for a demo, but it is not a good model for a real secure protocol.

X25519 and HKDF solved a different problem. They allowed the client and server to create fresh session keys for every connection without sending the actual secret over the network.

But there was still a hole.

The client received a public key from “the server,” but it had no way to know whether that public key really belonged to the server. The protocol could protect traffic after the handshake, but the handshake itself was not authenticated.

That means a man-in-the-middle could sit between the client and server and do this:

Client  <---- key exchange ---->  Attacker  <---- key exchange ---->  Server

From the client’s point of view, everything looks fine. It completed a key exchange and derived keys.

From the server’s point of view, everything also looks fine. It completed a key exchange and derived keys.

But the attacker is in the middle of both secure channels.

This is the uncomfortable lesson:

A secure key exchange with an unauthenticated peer can still give you a secure channel to the attacker.

That is why Part 4 exists.

---

Encryption Is Not the Same as Trust

It is easy to mix these ideas together because HTTPS makes them feel like one thing.

When we open a website over HTTPS, we usually think:

The connection is encrypted, so it is secure.

But real TLS gives us several properties at the same time. Encryption is only one of them.

A useful way to separate the ideas is this:

Encryption answers:
Can outsiders read the data?

Integrity answers:
Can outsiders modify the data without being detected?

Key exchange answers:
Can both sides create fresh session keys?

Authentication answers:
Do I know who is on the other side?

Before Part 4, our protocol had the first three. It did not have the fourth.

That distinction matters because an attacker does not always need to break encryption. Sometimes the attacker only needs to become the endpoint that you encrypt to.

If the client encrypts data to the attacker’s key, the encryption still works. The math is not broken. AES-GCM still protects the records. HKDF still derives keys. X25519 still creates a shared secret.

The problem is not the cryptography. The problem is that the client trusted the wrong public key.

So the next question becomes simple:

How does the client know that the server’s handshake key belongs to the real server?

This is where certificates enter the story.

---

What Certificates Actually Add

A certificate is not magic. It is also not just a random file that makes browsers happy.

At a practical level, a certificate connects an identity to a public key.

For example, a server certificate says something like:

This public key belongs to this server identity.

But the client should not just believe that statement because the server said so. Anyone can generate a key pair and create a file that claims to be example.com.

So certificates are signed.

That means another key, usually belonging to a Certificate Authority, signs the certificate data. The client can then verify the signature using the Certificate Authority’s public key.

In the real Web PKI, this usually forms a chain:

Root CA
  signs
Intermediate CA
  signs
Server Certificate

The root certificate is already trusted by the client’s system or browser. The server sends its certificate chain during the handshake. The client verifies each signature in the chain until it reaches a trusted root.

In my simplified implementation for Part 4, I use the same conceptual model:

Root CA
  ↓
Intermediate CA
  ↓
Server Certificate

The point is not to recreate all of Web PKI. The point is to make the trust chain visible.

The client does not trust the server certificate because the server sent it. The client trusts it because it can verify that the certificate was signed through a chain that ends at a trusted root.

Now the client has something it did not have before:

A public identity key that is connected to the server certificate and can be verified through a certificate chain.

But there is still one more important step.

---

Why the Server Must Sign the Handshake

A certificate chain proves that a certificate is valid.

It does not automatically prove that the server currently speaking in this connection owns the private key for that certificate.

That difference is important.

If the server only sends a certificate chain, an attacker could potentially copy that public certificate chain and send it to the client. Public certificates are public. They are not secrets.

So the server must prove ownership of the corresponding private key.

In real TLS, this is done with a handshake signature. In TLS 1.3, the server signs data derived from the handshake transcript. This binds the server’s authenticated identity to the exact handshake that is happening now.

In my simplified Part 4 implementation, I use the same core idea, but in a smaller form.

The server has two different types of keys:

Long-term identity key
= connected to the server certificate

Ephemeral X25519 key
= used only for this connection’s key exchange

The server sends its ephemeral X25519 public key, its certificate chain, and a signature over the handshake data.

The client verifies three things:

1. Is the certificate chain valid?

2. Does the server certificate contain the expected identity key?

3. Did the server sign this handshake using the private key that matches the certificate?

This is the key conceptual step.

The ephemeral X25519 key gives us fresh session keys. The certificate gives us identity. The signature connects both worlds together.

Without that signature, the certificate and the key exchange are two separate facts.

With the signature, the server says:

I own the private key for this certificate, and I am binding that identity to this ephemeral key exchange.

That is what stops the man-in-the-middle from silently replacing the handshake key.

---

The Architecture of Part 4

After Part 4, the handshake looks roughly like this:

Client
  |
  |  ClientHello
  |  ephemeral X25519 public key
  |
  v
Server
  |
  |  ServerHello
  |  ephemeral X25519 public key
  |  certificate chain
  |  handshake signature
  |
  v
Client

Then both sides derive the shared secret using X25519:

client private key + server public key
server private key + client public key

Both sides arrive at the same shared secret without sending that secret over the network.

Then HKDF turns that shared secret into actual session keys.

Then AES-GCM protects the application records.

The important change is that the client no longer accepts the server’s ephemeral public key blindly. It checks whether the authenticated server signed the handshake.

The complete shape now looks like this:

Certificate chain
  proves server identity

Handshake signature
  binds server identity to the ephemeral key exchange

X25519
  creates a fresh shared secret

HKDF
  derives directional session keys

AES-GCM
  protects application records

This is still a simplified protocol, but the main pieces now line up with the real TLS story much better.

---

What We Built in Code

For this part, I added a small certificate infrastructure to the project.

The implementation generates a simple hierarchy:

Root CA
Intermediate CA
Server Certificate

The server uses the server certificate and private key as its long-term identity. During the handshake, it still creates a fresh ephemeral X25519 key pair for the current connection.

That distinction matters.

The long-term certificate key is not used to encrypt application data. It is used to prove identity.

The ephemeral X25519 key is not used as identity. It is used to create a fresh shared secret for this connection.

This separation is one of the most important design ideas in modern TLS. Long-term keys authenticate. Ephemeral keys protect the session.

The simplified Part 4 flow is:

1. Client creates an ephemeral X25519 key pair.

2. Client sends its public key.

3. Server creates an ephemeral X25519 key pair.

4. Server sends:
   - its ephemeral public key
   - certificate chain
   - signature over handshake data

5. Client verifies the certificate chain.

6. Client verifies the handshake signature.

7. Both sides derive the shared secret with X25519.

8. Both sides derive session keys with HKDF.

9. Application data is protected with AES-GCM.

The full code is in the GitHub repository:

https://github.com/DmytroHuzz/rebuilding_tls

The full technical walkthrough is here:

https://dmytrohuzz.github.io/rebuilding_tls/part_4/walkthrough/walkthrough.html

I intentionally keep the article focused on the protocol idea rather than pasting the whole implementation here. Long code blocks inside an article often create an illusion of depth, but they usually make the article harder to read.

The repository is the right place for the full implementation. The article is the right place for the explanation.

---

What This Still Is Not

This is not real TLS.

That sentence is important.

This project is an educational reconstruction of some core TLS ideas. It is not a library. It is not a production protocol. It is not something that should protect real traffic.

Real TLS has many more details and much stronger guarantees around the handshake. For example, real TLS 1.3 binds the handshake with a transcript hash. It supports negotiation, extensions, certificate validation rules, revocation mechanisms, session resumption, alerts, many edge cases, and years of hardening against attacks that are easy to miss when building a small protocol.

My version is intentionally smaller.

It is useful because it makes the main ideas visible:

Why encryption alone is not enough.

Why integrity must be added.

Why fixed keys are weak.

Why key exchange gives fresh session keys.

Why key exchange is still not authentication.

Why certificates exist.

Why the server must sign the handshake.

Why TLS has the shape it has.

That is the real goal of this series.

Not to replace TLS, but to make TLS less mysterious.

Try It Yourself

The project is public and runnable.

The main repository is here:

https://github.com/DmytroHuzz/rebuilding_tls

The Part 4 walkthrough is here:

https://dmytrohuzz.github.io/rebuilding_tls/part_4/walkthrough/walkthrough.html

The complete series landing page is here:

Rebuilding TLS From Scratch — My Complete Learning Journey

If you want to understand the path from the beginning, I recommend reading the series in order. Each part fixes one problem and reveals the next one.

Part 1 starts with encryption. Part 2 adds integrity. Part 3 adds key exchange and session keys. Part 4 adds authentication through certificates and a handshake signature.

That sequence matters because it shows why TLS is not just “encryption.” It is a stack of answers to different problems.

---

Summary

Before Part 4, the protocol could create an encrypted channel, but it could not prove who was on the other side.

That is a serious problem.

Encryption protects data from being read. Integrity protects data from being modified. Key exchange creates fresh session keys. But authentication tells the client whether it is talking to the real server or to an attacker in the middle.

In Part 4, I added that missing authentication layer.

The client now verifies a certificate chain and checks a handshake signature. The server uses a long-term identity key to authenticate itself, while still using an ephemeral X25519 key for the actual key exchange. HKDF derives session keys, and AES-GCM protects application data.

The result is still not real TLS, but it now has the core shape:

authenticated handshake
fresh session keys
protected records

And that is the point of this whole series.

TLS is hard to understand when you only look at the final protocol. There are too many details, too many names, too many moving parts.

But when you rebuild it step by step, each piece starts to make sense.

You first feel the problem.

Then you add the missing mechanism.

Then you see why the real protocol looks the way it does.