Dive Deeper into TLS: Understanding TLS Certificates and Secure Communication

Understanding TLS Certificates and Secure Communication

In this post, we’ll cover the absolute basics of TLS certificates, why you need them, and how they can be used to secure communication over SSH or web servers. Whether you’re new to security or brushing up on the fundamentals, this guide will walk you through each concept clearly and from the ground up.

---

What is a TLS Certificate?

A TLS certificate is used to establish trust between two parties during a network transaction. When a client (like a browser) connects to a web server, TLS certificates:

• Encrypt communication between client and server
• Authenticate that the server is legitimate

---

Why is Encryption Necessary?

Let’s look at an example.

Imagine a user accessing their online banking site over an unsecured connection. Any credentials typed in (like username and password) would be sent in plain text over the network. A hacker sniffing the network could easily read these credentials and access the user’s account.

To prevent this, we need encryption.

---

What is Encryption?

Encryption converts readable data into an unreadable format using a key. Only someone with the correct key can decrypt and understand the message.

The process involves:

• Encrypting data before transmission
• Decrypting it on the receiving end using a key

However, there’s more than one way to do this.

---

Symmetric Encryption

With symmetric encryption, the same key is used to both encrypt and decrypt the data.

• The client encrypts data with a key
• The key must also be sent to the server to decrypt it

Problem:

The key itself is sent over the same network, making it vulnerable to interception. If an attacker gets the key, they can decrypt all messages.

---

Asymmetric Encryption

Asymmetric encryption uses two keys:

• A public key (shared openly)
• A private key (kept secret)

You encrypt data using the public key, but it can only be decrypted using the corresponding private key.

This way:

• The server keeps the private key safe
• The client encrypts a message with the public key
• Only the server can decrypt it

---

Real-World Example: SSH Access Using Key Pairs

1. A user generates a public/private key pair using:

   ssh-keygen
   

2. The private key (id_rsa) stays on their machine.
3. The public key (id_rsa.pub) is added to the server’s ~/.ssh/authorized_keys file.
4. Only users with the private key can access the server.

You can copy the same public key to multiple servers and use your private key to securely connect to all of them.

Other users can generate their own key pairs and have their public keys added to the server.

---

HTTPS and TLS in Web Communication

Let’s return to our web server example. How does TLS help?

Problem:

If we use symmetric encryption alone, we must transmit the symmetric key over the network. A hacker could intercept it.

Solution:

Use asymmetric encryption to securely exchange the symmetric key.

How It Works:

1. The server generates a public/private key pair.

2. When the client connects via https://, the server sends:

   • Its public key
   • In a certificate that includes details like domain name, issuer, etc.

3. The client (browser) uses the public key to:

   • Encrypt a symmetric key
   • Send the encrypted key to the server
4. The server decrypts the symmetric key with its private key.

Now both sides share a symmetric key for efficient encrypted communication.

---

The Role of Certificates

The TLS certificate sent by the server contains:

• The public key
• The domain name
• The issuer’s identity (who signed it)

Anyone can generate a certificate. But how do we verify it’s legitimate?

---

Fake Certificates and the Role of CAs

A hacker could:

• Create a fake version of a banking website
• Generate their own key pair
• Present a fake certificate

Your browser may encrypt data and communicate securely — with the hacker’s server.

This is why certificate validation is crucial.

The Solution:

• Use a Certificate Authority (CA) to sign your certificate
• Browsers trust certificates signed by trusted CAs

How to Get a Legitimate Certificate:

1. Generate a Certificate Signing Request (CSR):

   openssl req -new -key server.key -out server.csr
   

2. Send the CSR to a CA like DigiCert or Let’s Encrypt
3. The CA validates your identity
4. The CA signs your certificate using its private key
5. The certificate is returned to you and installed on your server

Browsers have the CA’s public keys built-in and can verify the certificate.

---

How Browsers Trust Certificates

• All major browsers maintain a list of trusted CAs

• When a browser receives a certificate:

  • It checks that it was signed by a trusted CA
  • It uses the CA’s public key to verify the signature
  • If it passes validation, the connection proceeds

This process ensures that users are truly communicating with the intended server, not a malicious one.

---

Private CAs and Internal Websites

Public CAs don’t help with internal applications (e.g., company intranet, payroll portals).

For this, you can run your own Private CA:

• Install the CA’s public key in your organization’s browsers
• Use it to issue certificates for internal apps

---

Summary: How TLS Works

1. Server:

   • Generates a public/private key pair
   • Requests a certificate from a trusted CA

2. CA:

   • Validates the request
   • Signs the certificate with its private key

3. Client:

   • Receives the certificate
   • Uses the CA’s public key to validate the certificate
   • Extracts the server’s public key
   • Generates a symmetric key
   • Encrypts it with the server’s public key

4. Server:

   • Decrypts the symmetric key using its private key
   • Now both client and server share the same symmetric key
   • All further communication is encrypted using symmetric encryption

---

Client Certificates (Mutual TLS)

While servers present certificates to clients, sometimes clients must also present certificates to prove their identity.

This is called Mutual TLS.

• The client generates a key pair and gets their certificate signed by a trusted CA
• The client presents the certificate during the handshake
• The server validates the client just as the client validates the server

Most websites don’t require this, but it’s common in enterprise environments or API authentication.

---

What is PKI?

Public Key Infrastructure (PKI) is the ecosystem that supports:

• Certificate Authorities
• Certificates
• Key generation and management
• Validation and revocation processes

It ensures trust and security in digital communication.

---

Naming Conventions

File Type	Description	Example
.key	Private key	server.key
.crt, .pem	Certificate with public key	server.crt, client.pem
.csr	Certificate Signing Request	mydomain.csr

A file with the word key in its name or extension is a private key. If it does not include key, it’s usually a public certificate.

---

Final Notes

• Asymmetric encryption secures the key exchange
• Symmetric encryption secures the data transfer
• Certificates validate identity
• CAs sign certificates to establish trust
• Browsers verify certificates using trusted root keys
• PKI manages the entire ecosystem

With this setup, TLS protects the integrity, confidentiality, and authenticity of web communications.

---

Thank you for reading.