How browsers and servers use TLS for Secure Communication ?

When your browser talks to https://example.com, how does it know it’s really that site, and not an impersonator?

That’s where TLS certificates and CAs (Certificate Authorities) come in.

Public-key cryptography uses two keys (asymmetric encrytion):

• Private key: Kept secret by the owner.

• Public key: Shared with anyone.

What one key encrypts, only the other can decrypt.

TLS: Step-by-Step Process

1. The Web Server Gets a Certificate

The server administrator:

1. Generates a private key and a CSR (Certificate Signing Request).

2. The CSR contains:

   • The public key

   • Domain name (Common Name)

   • Organization info

3. This CSR is sent to a Certificate Authority (CA) like Let’s Encrypt, DigiCert, etc.

4. The CA verifies the identity (e.g., via DNS or email)

5. If everything checks out, the CA returns a signed certificate

Now the server has:

• server.key → its private key

• server.crt → its public certificate, signed by a trusted CA

2. Browser Connects to the Server (HTTPS Request)

When you open https://example.com, the browser:

• Connects to the server on port 443

• The server responds with its certificate (server.crt)

3. The Browser Verifies the Certificate

The browser checks:

• Is the certificate issued by a trusted CA?

• Is it expired or revoked?

• Does the domain name match?

If all checks pass → browser proceeds with the TLS handshake

4. TLS Handshake and Secure Communication

During the handshake:

1. The browser generates a random symmetric session key

2. It encrypts this with the server’s public key from the certificate and sends it back to the server

3. The server decrypts it using its private key and gets the symmetric key from the client.

Now both browser and server share a symmetric key → used for fast, secure communication (AES, ChaCha20, etc.)

What is a CA and Why Is It Trusted?

A Certificate Authority (CA) is a trusted organization that validates identities and issues digital certificates.

Your browser (or OS) comes with a list of trusted root CAs, like:

• Let’s Encrypt

• DigiCert

• GlobalSign

• Google Trust Services

This is called the root trust store. If a server certificate is signed by one of these (or their intermediates), the browser trusts it.

Chain of Trust

Servers usually send:

• Their own certificate

• Any intermediate certificates
  The browser matches the top of the chain to a trusted root CA.

Optional: Client Certificates and Mutual TLS

In advanced setups like banking systems or API-to-API auth:

• Clients also have certificates.

• Server verifies the client’s identity.
  This is called mutual TLS (mTLS) and involves both sides proving who they are using certs.

Important Notes

• Your .crt file = your public certificate (public key signed by the CA server)

• Your .key file = your private key

• You must never expose your .key

• In Kubernetes, both are typically stored as a TLS secret

TLS certificates are the backbone of secure web communication. By understanding how public/private keys, CAs, and browser trust stores work together, you gain insight into how the internet remains (mostly) safe.

Next time you visit an HTTPS website, remember — a lot of cryptographic magic is happening silently to keep your data safe.