SSL Certificate: The Character Certificate of Your Web Request

I don’t know what should I write in intro so let me start directly.

If we hit a web request, our data travels from our device to the server.

Now what is the problem in this?

The data is in the form of plain text, so in the middle of the path, anyone can read this and manipulate our data.

This is called Man in the Middle Attack (MMA).

This is where encryption of our data is needed.

There are two ways to encrypt and decrypt our data.

1. Symmetric Encryption
2. Asymmetric Encryption

Symmetric Encryption

In symmetric encryption, the client and server use the same key for encryption and decryption.

Client encrypts the data using the Symmetric key and sends it to Server.

Server decrypts the data using the same key.

Use the same key for encryption and decryption.

Problem in Symmetric Encryption

In Symmetric Encryption, a Man in the Middle Attack can also happen.

The problem is that both the client and server need to have the same Symmetric key.

But how will the client securely share this key with the server?

If the client sends the Symmetric key through the network, an attacker can intercept the key.

Now the attacker has the key which can decrypt the data.

So the problem is not just encryption.

The problem is:

How can we securely establish/share a key between the client and server?

To solve this problem, Asymmetric Encryption came into the picture.

Asymmetric Encryption

In Asymmetric Encryption, we use two different keys.

1. Public Key - This key can be shared with everyone (For Encryption of data).
2. Private Key - This key is kept secret (For Decryption of data).

Server generates both the keys, public key is available to everyone but private key is only available to the server.

Server sends the public key to the client.

Client can use the server’s public key as part of the process of establishing a secure connection.

The private key remains with the server.

But there is still a problem.

An attacker can also generate their own public and private key pair.

When the server sends its public key to the client, the attacker can intercept it. Instead of forwarding the server’s public key, the attacker sends their own public key to the client.

Now the client thinks that the attacker’s public key actually belongs to the server.

When the client sends encrypted data, it is encrypted using the attacker’s public key. The attacker can then use their private key to access the data, read or modify it, and send it to the server.

From the server’s perspective, everything looks normal.

The server can also send data back to the client, and the attacker can intercept and manipulate that communication as well.

If anyone can access a server’s public key, how does the browser verify that the key actually belongs to the intended server and not an attacker pretending to be it?

To solve this problem, SSL Certificate came into the picture.

SSL Certificate

Now the problem is not encryption.

We already have a way to use cryptography to establish a secure connection.

The actual problem is:

How does the client know that the public key it received actually belongs to the real server?

Because anyone can generate a public-private key pair.

So we need someone we can trust who can verify:

“Yes, this public key actually belongs to this website.”

This is where Certificate Authority (CA) comes into the picture.

A Certificate Authority is a trusted organization that verifies the identity of a website and issues a digital certificate to it called SSL/TLS Certificate.

For example, Let’s Encrypt is a Certificate Authority.

When a server wants to use HTTPS, it has a public-private key pair.

The server keeps the private key secret.

The public key is included inside the SSL/TLS certificate.

The certificate contains information like:

Domain Name: example.com

Public Key: ABC123...

Issued By: Let's Encrypt

Valid From: ...
Valid Until: ...

Digital Signature: ...

Now the question is:

How does the client know that this certificate is actually trustworthy?

The certificate is digitally signed by a Certificate Authority.

Our browser and operating system already have a list of trusted Certificate Authorities.

So when the browser receives a certificate from the server, it checks things like:

• Is this certificate issued by a trusted Certificate Authority?
• Is the certificate still valid?
• Does the certificate belong to the domain we are trying to visit?
• Is the certificate’s signature valid?

If everything is valid, the browser can trust that the public key belongs to that website.

Now our previous problem is solved.

The attacker can still generate their own public-private key pair.

But they cannot simply create a valid certificate for example.com that the browser will trust.

Because the certificate needs to be issued and digitally signed by a trusted Certificate Authority.

So now the client can verify:

“Okay, this public key actually belongs to the server I wanted to talk to.”

And now we can establish a secure connection.

But one more thing

You might be thinking:

If we already have Asymmetric Encryption, why don’t we just use it for everything?

Because asymmetric cryptography is relatively expensive and slower compared to symmetric encryption.

So HTTPS doesn’t simply use asymmetric encryption for the entire communication.

Instead, it uses both.

Asymmetric cryptography is used during the TLS handshake to authenticate the server and establish the necessary shared secret.

Then symmetric encryption is used to encrypt the actual communication.

So the basic idea is:

Asymmetric Cryptography + SSL Certificate
        |
        | Establish secure connection
        | and shared secret
        ↓
Symmetric Encryption
        |
        | Encrypt actual data
        ↓
      HTTPS

This gives us both:

Identity + Security + Performance

And this is why when you visit:

https://example.com

your browser is not just blindly trusting the server.

It is performing a series of cryptographic checks before trusting the connection.

So, if we go back to our original problem:

Problem 1:
Data is travelling in plain text
        ↓
Solution:
Encryption

But then we found another problem:

Problem 2:
How do I know I am communicating
with the real server?
        ↓
Solution:
SSL/TLS Certificate

And that’s the whole idea behind an SSL Certificate.

SSL Certificate doesn’t let anyone fuck with your web request, which is why I call it the “character certificate” of your web request.