🔐 Module 04: SSL/TLS, Certificate Authorities & PKI

Core Focus: Symmetric vs Asymmetric Encryption, TLS 1.2 vs TLS 1.3 Handshake Packet Flows, Certificate Authorities (CA) & PKI Hierarchy, Step-by-Step Local Certificate Validation (Root Store, Digital Signatures, Chain of Trust, OCSP/CRL), Forward Secrecy (PFS), and Mutual TLS (mTLS) in Banking/Juspay Infrastructure.

📑 Table of Contents

1. Cryptography Fundamentals for Networks
   • 1.1 Symmetric vs Asymmetric Encryption
   • 1.2 Cryptographic Hashes & Digital Signatures
   • 1.3 Forward Secrecy (ECDHE)
2. Public Key Infrastructure (PKI) & Certificate Authorities
   • 2.1 The Chain of Trust (Root $\rightarrow$ Intermediate $\rightarrow$ Leaf)
   • 2.2 Structure of an X.509 Certificate
3. How Your Computer Validates a Certificate Locally
   • 3.1 The 5-Step Local Verification Algorithm
   • 3.2 Digital Signature Verification Math
   • 3.3 Revocation Checking: CRL vs OCSP vs OCSP Stapling
4. The SSL/TLS Handshake Deep Dive
   • 4.1 TLS 1.2 Handshake (2 RTT)
   • 4.2 TLS 1.3 Handshake (1 RTT & 0-RTT Resumption)
5. Mutual TLS (mTLS) in Payment Systems
6. Juspay & Payment Systems Real-World Context
7. High-Yield Interview Questions & Verbatim Answers

1. Cryptography Fundamentals for Networks

Security over the internet requires solving three distinct challenges:

1. Confidentiality (Privacy): Eavesdroppers cannot read data $\implies$ Encryption.
2. Integrity (Tamper-Proof): Data cannot be altered in transit $\implies$ Hashing / HMAC.
3. Authentication (Identity): Proof of who you are talking to $\implies$ Digital Signatures & Certificates.

1.1 Symmetric vs Asymmetric Encryption

[!IMPORTANT] Hybrid Encryption (The Best of Both Worlds):
HTTPS does not encrypt website data with RSA/ECC. It uses Asymmetric Cryptography for 1 second during the handshake to authenticate and negotiate a temporary shared Symmetric Session Key, and then uses AES-GCM (Symmetric) to encrypt all actual HTTP traffic.

1.2 Cryptographic Hashes & Digital Signatures

• Cryptographic Hash (SHA-256): One-way mathematical function producing a fixed-size 256-bit fingerprint. Any 1-bit change produces a drastically different hash (avalanche effect).
• Digital Signature:
  • The signer computes: $\text{Hash} = \text{SHA-256}(\text{Data})$.
  • The signer encrypts the hash using their Private Key: $$\text{Digital Signature} = \text{Encrypt}_{\text{PrivateKey}}(\text{Hash})$$
  • Anyone holding the signer's Public Key can decrypt the signature to reveal the expected hash and compare it with the independently computed hash of the data. If they match, authenticity and integrity are proven.

1.3 Forward Secrecy (PFS — Perfect Forward Secrecy)

• The Danger of Static RSA Key Exchange: In legacy TLS, the client encrypted the pre-master secret with the server's public RSA key. If an adversary recorded years of encrypted traffic and eventually stole the server's private key, they could decrypt all past historical traffic!
• PFS via Ephemeral Diffie-Hellman (ECDHE):
  • Generates a fresh, temporary key pair for every single session.
  • Even if the server's permanent private key is compromised in the future, past recorded sessions cannot be decrypted.
  • TLS 1.3 bans static RSA key exchange and mandates Ephemeral Diffie-Hellman.

2. Public Key Infrastructure (PKI) & Certificate Authorities

How does a browser know that the public key received from api.juspay.in genuinely belongs to Juspay and not an adversary performing a Man-in-the-Middle (MitM) attack? Certificate Authorities (CAs) solve this.

2.1 The Chain of Trust

[!NOTE] Why Intermediate CAs?
Root CA private keys are stored on air-gapped Hardware Security Modules (HSMs) in high-security vaults. If a Root CA key were compromised, all certificates on the internet would be invalidated. Intermediate CAs handle day-to-day issuance; if an intermediate CA is compromised, only that intermediate is revoked without affecting the Root CA.

2.2 Structure of an X.509 Certificate

An X.509 certificate contains:

1. Subject: Entity being certified (CN=api.juspay.in, O=Juspay Technologies Pvt Ltd).
2. Subject Alternative Name (SAN): List of valid hostnames (api.juspay.in, *.juspay.in).
3. Subject Public Key Info: Algorithm (e.g., RSA 2048-bit or ECC P-256) and the actual Public Key.
4. Issuer: Name of issuing CA (DigiCert Global G2 TLS CA).
5. Validity Period: NotBefore: Aug 01 2026, NotAfter: Aug 01 2027 (Max lifetime is currently 398 days).
6. Digital Signature: Signature generated by the Issuer CA's private key over the certificate fields.

3. How Your Computer Validates a Certificate Locally

This is one of the most frequently asked questions in high-bar interviews.

3.1 The 5-Step Local Verification Algorithm

1. Step 1: Locate the Root CA in the Local Trust Store:
   • Operating Systems (Windows Certificate Manager certmgr.msc, macOS Keychain, Linux /etc/ssl/certs) and browsers (Mozilla Firefox) ship with a hardcoded Trust Store containing ~150 vetted Root CA certificates and their public keys.
   • The computer matches the Root CA name in the certificate chain against its pre-installed Root Store.
2. Step 2: Cryptographic Signature Verification (Walking Up the Chain):
   • Verifying Leaf Cert: The computer takes the Intermediate CA's Public Key and uses it to decrypt the Digital Signature on the Leaf Certificate. It hashes the Leaf Certificate body using SHA-256. If Decrypted_Signature == Computed_Hash, the Leaf Cert is authentic!
   • Verifying Intermediate Cert: The computer takes the Root CA's pre-installed Public Key (from local storage) and verifies the Intermediate CA's signature.
3. Step 3: Domain Name Matching:
   • The browser inspects the Subject Alternative Name (SAN) field in the Leaf Certificate.
   • If user typed api.juspay.in, the SAN must contain api.juspay.in or *.juspay.in. If not, browser shows ERR_CERT_COMMON_NAME_INVALID.
4. Step 4: Date & Expiration Verification:
   • The computer reads its local system clock. It verifies that: $$\text{NotBefore} \le \text{Current Time} \le \text{NotAfter}$$
   • If system clock is incorrect (e.g., set to year 2010), valid certificates will fail with NET::ERR_CERT_DATE_INVALID.
5. Step 5: Revocation Status Check:
   • Checks if the certificate was revoked before its expiration date (e.g., due to compromised private key).

3.2 Digital Signature Verification Math

3.3 Revocation Checking: CRL vs OCSP vs OCSP Stapling

4. The SSL/TLS Handshake Deep Dive

4.1 TLS 1.2 Handshake (2 RTT Overhead)

4.2 TLS 1.3 Handshake (Optimized 1 RTT)

TLS 1.3 (RFC 8446) overhauled the handshake to reduce connection setup time by 50% and eliminate legacy insecure ciphers:

• Key Difference: In TLS 1.3, the client guesses the key exchange algorithm and sends its Diffie-Hellman key share in the first message (ClientHello), allowing encryption to begin immediately after 1 RTT.

5. Mutual TLS (mTLS) in Payment Systems

Standard TLS provides One-Way Authentication (Client verifies Server identity, but Server accepts connections from anyone).
In Mutual TLS (mTLS), both parties authenticate each other using certificates.

Why mTLS is Mandatory in Payments:

• API Keys and Bearer tokens can be leaked, stolen, or logged in plaintext proxy logs.
• mTLS requires a cryptographic private key stored in an HSM or secure enclave. Even if an attacker intercepts network packets, they cannot impersonate the client without the private key.

6. Juspay & Payment Systems Real-World Context

7. High-Yield Interview Questions & Verbatim Answers

Q1: "How does your computer validate an SSL/TLS Certificate locally when you visit a website?"

Spoken Answer:
*"When the server presents its certificate chain (Leaf $\rightarrow$ Intermediate $\rightarrow$ Root), my computer performs a 5-step local verification:

1. Root Store Lookup: It matches the Root CA in the chain against its local operating system / browser Root Trust Store.
2. Digital Signature Verification: Starting from the trusted Root CA, it uses the CA's public key to decrypt the digital signature on the intermediate certificate and verifies the computed SHA-256 hash. It repeats this step down to the leaf certificate using the intermediate CA's public key.
3. Domain Matching: It verifies that the requested domain name matches the Subject Alternative Name (SAN) field.
4. Validity Window: It compares the system clock against the NotBefore and NotAfter timestamps.
5. Revocation Check: It checks if the certificate has been revoked via OCSP Stapling or CRL.
   If all checks pass, the identity is authenticated and session keys are derived."*

Q2: "Why do we use both Symmetric and Asymmetric encryption in HTTPS instead of just one?"

Spoken Answer:
*"We use both because each solves what the other lacks:

• Asymmetric Encryption (RSA/ECC) solves the key distribution problem—it allows two parties who have never met to authenticate identities and establish a shared secret over an untrusted network. However, it is computationally expensive (~1000x slower).
• Symmetric Encryption (AES-256-GCM) is blazingly fast and hardware-accelerated, but requires both parties to already share a secret key.

Therefore, HTTPS uses Hybrid Encryption: asymmetric crypto is used for only 1 RTT during the initial handshake to authenticate and negotiate a temporary session key, after which symmetric crypto encrypts all high-volume HTTP data."*

Q3: "What is Perfect Forward Secrecy (PFS) and why is it important?"

Spoken Answer:
*"Perfect Forward Secrecy is a property of cryptographic key exchange protocols (like Ephemeral Diffie-Hellman, ECDHE) where a unique, temporary session key is generated for every individual session.

Without PFS (such as in static RSA key exchange), if an adversary records encrypted network traffic for years and eventually compromises the server's long-term private key, they can decrypt all historical recorded communications. With PFS, compromising the server's private key does not compromise past session keys, keeping historical data secure."*

Q4: "What is Mutual TLS (mTLS) and where is it used in banking architectures?"

Spoken Answer:
*"In standard TLS, authentication is one-way: the client validates the server's identity. In Mutual TLS (mTLS), both the client and the server present X.509 digital certificates to authenticate each other.

It is heavily used in Banking APIs, UPI Switches, and Payment Gateways (like Juspay) for B2B server-to-server communication. It guarantees that only pre-approved partner servers with valid private keys can invoke sensitive financial endpoints, mitigating credential leakage and Man-in-the-Middle attacks."*