Skip to content

6.03 TLS Basics (certificate based authentication)

1️⃣ Why TLS Exists

Without encryption:

  • Credentials are sent in plain text
  • Attackers can sniff traffic
  • Sensitive data is exposed

Danger

Sending passwords over plain HTTP is insecure.
Always use HTTPS (TLS) for production systems.

TLS ensures:

  • 🔐 Encryption (confidentiality)
  • ✅ Server identity verification
  • 🛡 Protection against man-in-the-middle attacks

2️⃣ Encryption Basics

🔹 Symmetric Encryption

  • One shared key
  • Same key encrypts and decrypts
  • Fast and efficient

Problem: - Key must be shared securely - If intercepted → communication compromised

Warning

Symmetric encryption alone is not enough for secure internet communication.

🔹 Asymmetric Encryption (Public/Private Keys)

Uses a key pair:

  • 🔐 Private Key (kept secret)
  • 🔓 Public Key (shared openly)

Key Principle:

  • Data encrypted with one key can only be decrypted with the other.
  • You cannot encrypt and decrypt with the same key.

Note

If you encrypt with the public key → only the private key can decrypt.
If you encrypt with the private key → anyone with the public key can decrypt.

3️⃣ SSH Key Authentication (Asymmetric in Action)

Used for secure server access.

Key Generation

ssh-keygen

Generates:

File Purpose
id_rsa Private Key (keep secret)
id_rsa.pub Public Key

Public key is added to:

~/.ssh/authorized_keys

Success

You can copy the same public key to multiple servers and use one private key to access all securely.

SSH Production Best Practices

✅ DO

Success

  • Disable password authentication
  • Use 4096-bit RSA or Ed25519 keys
  • Protect private keys with passphrases
  • Restrict SSH by IP if possible
  • Rotate keys periodically

❌ DON'T

Danger

  • Do NOT share private keys
  • Do NOT store private keys in Git
  • Do NOT use weak key sizes
  • Do NOT allow root login over SSH

4️⃣ TLS Handshake (How HTTPS Works)

TLS combines both encryption types.

Step-by-Step Flow

  1. Client connects via HTTPS
  2. Server sends its certificate (contains public key)
  3. Client validates certificate
  4. Client generates symmetric key
  5. Client encrypts symmetric key using server's public key
  6. Server decrypts using private key
  7. Communication continues using symmetric encryption

Success

Asymmetric encryption secures key exchange.
Symmetric encryption secures ongoing communication.

5️⃣ What Is a Certificate?

A certificate contains:

  • Server identity (CN / SAN)
  • Public key
  • Issuer (CA)
  • Expiry date
  • Digital signature

Common extensions:

Type Example
Certificate (Public Key) .crt, .pem
Private Key .key, *-key.pem

Tip

If filename contains "key", it is usually a private key.

6️⃣ Self-Signed vs CA-Signed Certificates

🔹 Self-Signed

  • Signed by itself
  • Not trusted by browsers
  • Used for labs/internal testing

Warning

Never use self-signed certificates for public production websites.

🔹 CA-Signed Certificate

Signed by trusted Certificate Authority.

Browsers trust these CAs because:

  • CA public keys are built into browsers
  • CA signs server certificate with its private key
  • Browser verifies signature using CA public key

7️⃣ Certificate Signing Process

Step 1: Generate Private Key

openssl genrsa -out server.key 4096

Step 2: Generate CSR

openssl req -new -key server.key -out server.csr -subj "/C=US/ST=CA/O=MyOrg/CN=my-domain.com"

Step 3: CA Signs Certificate

  • CA validates domain ownership
  • Signs certificate
  • Sends back signed certificate

Success

The signed certificate proves your server identity.

8️⃣ Man-in-the-Middle Protection

Without CA validation:

  • User connects securely to attacker
  • Communication encrypted — but wrong server

With CA validation:

  • Browser checks certificate issuer
  • Invalid signature → browser warning

Danger

TLS without certificate validation does NOT guarantee identity.

9️⃣ Mutual TLS (mTLS)

Server validates client certificate.

Used in:

  • Kubernetes API authentication
  • Service mesh (Istio, Linkerd)
  • Zero-trust architectures

Tip

mTLS provides identity verification on both sides.

🔟 Production Best Practices

✅ DO

Success

  • Always use HTTPS
  • Use 2048-bit+ RSA or ECDSA
  • Use trusted CA
  • Enable HSTS
  • Use strong cipher suites
  • Rotate certificates before expiry
  • Protect private keys with strict file permissions (600)
  • Use automated renewal (cert-manager, Let's Encrypt)

❌ DON'T

Danger

  • Do NOT expose private keys
  • Do NOT disable certificate validation
  • Do NOT use expired certificates
  • Do NOT use weak TLS versions (TLS 1.0/1.1)
  • Do NOT hardcode private keys in containers
  • Do NOT commit certificates to Git

🎯 Summary

  • Asymmetric encryption secures key exchange
  • Symmetric encryption secures data transfer
  • Certificates prove server identity
  • Certificate Authorities establish trust
  • TLS protects against eavesdropping and impersonation

Quote

Encryption protects data.
Certificates protect identity.
Proper key management protects everything.