Understanding TLS: Certificates, Key Exchange, Session Keys, TLS 1.2, TLS 1.3 and mTLS Explained

Understanding TLS: From Certificates to Secure Communication

For a long time, I understood TLS only at a very high level.

Websites use HTTPS. Browsers show a padlock icon. Certificates are involved somewhere. Communication is encrypted.

But when I started digging deeper, I realized I had several misconceptions about how TLS actually works.

This learning journey helped me connect concepts that I previously understood in isolation: certificates, public/private keys, symmetric encryption, asymmetric encryption, session keys, and mutual TLS.

This article is a summary of what I learned.

The Misconception I Had

I used to think that the TLS certificate itself was responsible for encrypting all communication between a client and a server.

What I learned is that a certificate has a much simpler purpose:

A TLS certificate proves the identity of the server and provides its public key.

The actual encryption of application data happens later using symmetric encryption algorithms such as AES.

Once I understood this, many other concepts started making sense.

Cryptography vs Encryption

These terms are often used interchangeably, but they are not the same.

Cryptography is the broader field of securing information.

It includes:

• Encryption
• Decryption
• Hashing
• Digital Signatures
• Certificates
• Key Exchange

Encryption is simply one technique within cryptography.

Its purpose is to convert readable information into an unreadable format and back again.

Symmetric Encryption

In symmetric encryption, the same key is used for both encryption and decryption.

Example:

Key = SECRET123

Encrypt: Hello → Ciphertext

Decrypt: Ciphertext → Hello

Popular symmetric algorithms include:

• AES
• ChaCha20

Advantages

• Extremely fast
• Suitable for encrypting large amounts of data

Challenge

Both parties need the same key.

This raises an important question:

How can two parties securely obtain the same key over an untrusted network?

This is where asymmetric cryptography becomes useful.

Asymmetric Encryption

Asymmetric cryptography uses two keys:

• Public Key
• Private Key

The public key can be shared openly.

The private key must remain secret.

Anything encrypted using the public key can only be decrypted using the corresponding private key.

Examples include:

• RSA
• ECDSA
• ECDHE

Asymmetric cryptography solves the trust and key distribution problem, but it is significantly slower than symmetric encryption.

Using it for all communication would be inefficient.

Why TLS Uses Both

TLS combines the strengths of both approaches.

Asymmetric Cryptography

Used for:

• Identity verification
• Establishing trust
• Key exchange

Symmetric Cryptography

Used for:

• Encrypting actual application traffic

The overall flow looks like:

Certificate ↓ Verify Identity ↓ Key Exchange ↓ Generate Session Key ↓ AES Encryption ↓ Data Transfer

This combination provides both security and performance.

Understanding TLS Certificates

A TLS certificate contains information such as:

• Domain Name
• Public Key
• Issuer
• Expiry Date
• Digital Signature

A certificate essentially says:“I am the owner of this domain, and here is my public key”

However, anyone can create a certificate.

The important question becomes:

Why should a browser trust it?

Certificate Authorities (CAs)

A certificate signed by its own creator is known as a self-signed certificate.

Although technically valid, browsers do not trust such certificates by default.

Instead, certificates are typically signed by trusted Certificate Authorities (CAs) such as:

• DigiCert
• GlobalSign
• Let’s Encrypt
• Sectigo

The process usually works like this:

Step 1

Generate a key pair:

• Private Key
• Public Key

Step 2

Create a CSR (Certificate Signing Request).

The CSR contains:

• Domain Name
• Public Key
• Organization Details

Step 3

Submit the CSR to a CA.

Step 4

The CA validates ownership of the domain.

Step 5

The CA signs the certificate using its private key.

Step 6

The signed certificate is returned and installed on the server.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Server Owner | | Generate Key Pair |

• → Private Key |
• → Public Key | v Create CSR | v Send CSR to CA | v CA Validates Domain | v CA Signs Certificate | v Signed Certificate | v Installed on Server

How Browsers Validate Certificates

When a server sends its certificate, the browser performs several checks:

• Does the domain name match?
• Has the certificate expired?
• Was it signed by a trusted CA?
• Is the certificate chain valid?

Browsers and operating systems already contain trusted root certificates.

Examples include:

• DigiCert Root CA
• GlobalSign Root CA
• Let’s Encrypt Root CA

These root certificates contain the public keys of trusted Certificate Authorities.

The browser uses these public keys to verify the signature on the server’s certificate.

If validation succeeds, the certificate is trusted.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Browser | | HTTPS Request | v Server | | Sends Certificate | v Browser |

• → Domain Match? |
• → Certificate Expired? |
• → Signed by Trusted CA? |
• → Chain of Trust Valid? | v Connection Trusted

What Happens During the TLS Handshake?

At a high level:

TCP Handshake ↓ ClientHello ↓ ServerHello ↓ Certificate ↓ Certificate Validation ↓ Key Exchange ↓ Session Key Generation ↓ Encrypted Communication

Once the handshake completes, all future communication is encrypted.

Shared Secret vs Session Key

This was one of the concepts that initially confused me.

I assumed the key involved in the handshake was the same key used to encrypt application traffic.

That is not exactly true.

Shared Secret

Created during the key exchange process.

Session Key

Derived from:

• Shared Secret
• Client Random
• Server Random

The session key is then used by AES to encrypt actual data.

Conceptually:

Shared Secret

• Client Random

• Server Random ↓ Key Derivation Function ↓ Session Key ↓ AES Encryption

TLS 1.2 vs TLS 1.3

One area that helped me understand TLS better was learning how TLS 1.2 and TLS 1.3 establish secure communication differently.

Both versions aim to achieve the same goal:

• Verify identity
• Establish trust
• Create a shared secret
• Generate session keys
• Encrypt communication

However, the process differs significantly.

TLS 1.2 (Simplified View)

ClientHello ↓ ServerHello ↓ Certificate ↓ Certificate Validation ↓ Client generates Pre-Master Secret ↓ Encrypts it using Server Public Key ↓ Server decrypts it using Private Key ↓ Both derive Session Keys ↓ Encrypted Communication

This model commonly relied on RSA-based key exchange.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Client Server | | | — — — ClientHello — — — — — — — — -> | | | | ← — ServerHello — — — — — — — — — | | ← — Certificate — — — — — — — — — | | | | Verify Certificate | | | | Generate Pre-Master Secret | | Encrypt with Server Public Key | | — — — Encrypted Secret — — — — — → | | | | Shared Secret | | ↓ | | Session Key Generation | | ↓ | |========== AES Encryption ==========|

Limitation

If an attacker somehow obtained the server’s private key and had previously recorded TLS traffic, historical sessions could potentially be decrypted.

TLS 1.3

TLS 1.3 uses ECDHE-based key exchange.

Instead of the client generating and sending a secret, both sides contribute information to generate a shared secret.

ClientHello

• Client Random
• Client ECDHE Value

↓

ServerHello

• Server Random
• Server ECDHE Value

↓

ECDHE Exchange

↓

Shared Secret

↓

Shared Secret

• Client Random
• Server Random

↓

HKDF

↓

Session Keys

↓

Encrypted Communication

Notice that the shared secret itself is never transmitted over the network.

Both sides independently calculate the same value.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Client Server | | | ClientHello | | Client Random | | Client ECDHE Value | | — — — — — — — — — — — — — — — — — -> | | | | ← — — — — — — — — — — — — — — — — -| | ServerHello | | Server Random | | Server ECDHE Value | | | | | | ECDHE Values | | ↓ | | Shared Secret | | ↓ | | Shared Secret | | + Client Random | | + Server Random | | ↓ | | HKDF | | ↓ | | Session Keys | | ↓ | |====== AES Encryption ============= |

Benefits of TLS 1.3

Faster Handshake

Fewer round trips are required.

Forward Secrecy

Even if a server’s private key is compromised in the future, previously captured traffic remains protected.

Stronger Security

Older and weaker cryptographic options have been removed.

Simpler Protocol

TLS 1.3 eliminates many legacy features that existed for backward compatibility.

Client Certificates and Mutual TLS

Most websites only require the client to validate the server.

For example:

Browser ↓ Validates Google Certificate

Google does not typically validate a client certificate.

Instead, user authentication happens using:

• Username
• Password
• MFA
• OAuth

However, some enterprise systems require both sides to prove their identity.

This is called Mutual TLS (mTLS).

Client validates Server ↓ Server validates Client

Common use cases include:

• Banking APIs
• Enterprise integrations
• VPNs
• Service-to-service communication

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Normal TLS

Client ← — — Validates — — — Server

Mutual TLS (mTLS)

Client ← — — Validates — — -> Server Both Validate

How Client Certificates Work

The process is similar to server certificates.

Generate Key Pair

• client.key
• Public Key

Create CSR

client.csr

Submit CSR to CA

CA Signs Certificate

Returns:

client.crt

The client then uses:

• client.crt
• client.key

during TLS authentication.

Unlike normal web browsing, the server validates the client certificate before granting access.

Final Thoughts

Before exploring TLS in detail, I viewed certificates, encryption, HTTPS, and key exchange as separate topics.

Understanding how these pieces fit together helped me build a much clearer picture of how secure communication actually works.

My biggest takeaway was:

• Certificates establish trust.
• Key exchange creates a shared secret.
• Session keys are derived from that secret.
• AES encrypts the actual data.
• TLS combines asymmetric and symmetric cryptography to achieve both security and performance.

Every HTTPS connection we make depends on these concepts working together seamlessly behind the scenes.