Public Key Infrastructure (PKI), SSL, and TLS

The Chain of Trust (PKI Architecture)

graph TD
    subgraph Client_PC [Client Side / Browser Trust Store]
        Root[Root CA
Self-Signed
Contains: Root Public Key]
    end

    subgraph Server_Bundle [Server Side / TLS Handshake]
        Intermediate[Intermediate CA
Issuer: Root CA
Contains: Interm. Public Key
Signature: From Root Priv Key]
        Leaf[Leaf Certificate
Issuer: Intermediate CA
Contains: Server Public Key
Signature: From Interm. Priv Key]
    end

    %% The Issuance Path (Logic)
    Root -- "1.Issues / Signs" --> Intermediate
    Intermediate -- "2.Issues / Signs" --> Leaf

    %% The Verification Path (Actual Browser Action)
    Leaf -. "3.Browser verifies Leaf Sig
using Intermediate Public Key" .-> Intermediate
    Intermediate -. "4.Browser verifies Interm. Sig
using Root Public Key" .-> Root

    %% Styling
    style Root fill:#ff9,stroke:#333,stroke-width:4px
    style Intermediate fill:#bbf,stroke:#333,stroke-width:2px
    style Leaf fill:#bfb,stroke:#333,stroke-width:2px

    linkStyle 2,3 stroke-width:2px,fill:none,stroke:red,stroke-dasharray: 5 5;

The Mechanics of Verification (Digital Signatures)

flowchart LR
    direction TB
    %% Subgraph 1: The Origin (Issuance)
    subgraph CA_Side ["1. CA Side: Signing
(Issuance)"]
        direction TB
        TBS["TBS Certificate
(Domain, Expiry, PubKey)
*Excludes Signature field*"]

        TBS -->|1. Hash Function| Hash1[Original Hash]

        PrivKey["CA Private Key
(Kept Offline/Secret)"]

        Hash1 -->|Input A| SignAlgo[Encryption Step]
        PrivKey -->|Input B| SignAlgo

        SignAlgo --> FinalSig[Digital Signature]
    end

    %% Subgraph 2: The Destination (Verification)
    subgraph Browser_Side [2. Browser Side: Verification]
        direction TB
        RecvCert[Received Certificate]

        RecvCert -->|Split| Body[Body Data]
        RecvCert -->|Split| SigBlock[Signature Block]

        Body -->|2. Hash Function| Hash2[Calculated Hash]

        PubKey["CA Public Key
(From Trust Store/Chain)"]

        SigBlock -->|Input A| VerifAlgo[Decryption Step]
        PubKey -->|Input B| VerifAlgo

        VerifAlgo --> Hash3[Decrypted Hash]

        Hash2 <-->|3. MUST MATCH| Hash3
    end

    %% Connecting the two worlds
    FinalSig -.->|Sent over Wire| RecvCert
    TBS -.->|Sent over Wire| RecvCert

    %% Styling
    style Hash2 fill:#bfb,stroke:#333
    style Hash3 fill:#bfb,stroke:#333
    style PrivKey fill:#f96,stroke:#333
    style PubKey fill:#69f,stroke:#333

The TLS 1.3 Handshake

sequenceDiagram
    autonumber
    participant Client as Browser
    participant Server as Web Server

    rect rgb(240, 250, 255)
        note right of Client: Phase 1: Key Exchange (Plain Text)
        note over Client, Server: Privacy Leak: SNI is visible here so Server knows which Cert to pick.

        Client->>Server: Client Hello
+ Random Nonce
+ SNI: "example.com"
+ Key Share (Client PubKey X)
    end

    rect rgb(255, 248, 240)
        note left of Server: 1. Selects Cert based on SNI
2. Generates Ephemeral Key Y
3. Calculates Handshake Secret

        Server->>Client: Server Hello
+ Key Share (Server PubKey Y)
    end

    rect rgb(230, 255, 230)
        note right of Client: ENCRYPTION STARTS HERE
        note over Client, Server: Keys derived from (X + Y).
The following messages are hidden from spies.
    end

    rect rgb(255, 255, 220)
        note right of Client: Phase 2: Authentication (Encrypted)

        Note over Server: The "Server Flight" of messages:
        Server->>Client: Wrapper: Encrypted Handshake Message
1. EncryptedExtensions (Protocol details)
2. Certificate (The Leaf + Chain)
3. CertificateVerify (Signed Hash of transcript)

        Server->>Client: Finished (HMAC of transcript)

        note left of Client: Browser verifies:
1. Cert Chain (Root Trust)
2. Signature (Identity Proof)
3. HMAC (Integrity)

        Client->>Server: Finished (HMAC)
    end

    rect rgb(240, 240, 240)
        note over Client, Server: Phase 3: HTTP Traffic (Application Keys)
        note right of Client: Keys are rotated again for extra security.
        Client->>Server: [ GET /account ]
        Server->>Client: [ 200 OK (Data...) ]
    end

TLS 1.3 "Zero Round Trip" (0-RTT)

sequenceDiagram
    autonumber
    participant Client as Browser
    participant Server as Web Server

    note over Client, Server: Pre-requisite: Client has a "Session Ticket" (PSK) from a previous visit.

    rect rgb(255, 245, 245)
        note right of Client: Phase 1: The "0-RTT" Blast (Weak Security)
        note right of Client: ⚠️ Warning: This data is NOT Forward Secure.
It is also vulnerable to Replay Attacks.

        Client->>Server: Client Hello
+ Key Share (X)
+ PSK Identity (Ticket)
+ { Encrypted Early Data: GET /home }

        note right of Client: Encrypted using PSK Only (No fresh Diffie-Hellman yet)
    end

    rect rgb(230, 255, 230)
        note left of Server: Server validates Ticket.
Accepts Early Data.
Mixes X + Y for full security.

        Server->>Client: Server Hello
+ Key Share (Y)
+ { Encrypted Ext: "Early Data Accepted" }
+ { Finished }
    end

    rect rgb(240, 240, 255)
        note right of Client: Phase 2: The Response (Strong Security)
        note left of Server: Server switches to Forward Secure Keys (PSK + DH).

        Server->>Client: [ 200 OK (HTML Body...) ]
    end

    note over Client, Server: Constraint: Only use 0-RTT for "Safe" methods (GET/HEAD).
Never use for "POST /transfer-money" due to Replay Risk.

mTLS with Selection Logic

sequenceDiagram
    autonumber
    participant Client as Client Device
(Has Wallet of Certs)
    participant Server as Server
(Configured with Trust Store)

    note over Client, Server: Phase 1: Encrypted Tunnel Established (Standard TLS 1.3)

    rect rgb(255, 255, 220)
        note right of Client: Phase 2: The Server's Challenge

        Server->>Client: { Encrypted Extensions }
1. CertificateRequest
"Please send Cert issued by: [MyCorporateRoot-v1, PartnerRoot-v2]"

        Server->>Client: { Finished }
    end

    rect rgb(230, 255, 230)
        note left of Client: Client Selection Logic (Deep Detail):
1. Client looks at Server's "Allowed CAs" list.
2. Client scans its Wallet.
3. Finds Cert signed by "MyCorporateRoot-v1".

        Client->>Server: { Encrypted Client Auth }
1. Client Certificate (Selected via Hint)
2. Certificate Verify (Signed with Client PrivKey)

        Client->>Server: { Finished }
    end

    rect rgb(240, 240, 240)
        note right of Client: Phase 3: Validation
        note left of Server: Server verifies Client Signature.
Server checks if Client Cert is in Revocation List (CRL/OCSP).

        Server->>Client: [ 200 OK: "Welcome, UserID: 123" ]
    end

Cross-Signing

graph TD
    subgraph User_Device [User's Trust Store]
        OldRoot["Old Root CA
(Trusted by Old Android)
Installed 2010"]
        NewRootTrust["New Root CA
(Trusted by Modern Chrome)
Installed 2020"]
    end

    subgraph Server_Chain [Certificate Chain Sent by Server]
        Leaf["Leaf Cert
(example.com)"]
        Inter["Intermediate CA"]
        NewRootCert["New Root CA
(The Cross-Signed Version)"]
    end

    %% The Standard Path (Modern)
    Leaf -->|Issued By| Inter
    Inter -->|Issued By| NewRootCert
    NewRootCert -.->|Matches| NewRootTrust

    %% The Legacy Path (Cross-Signed)
    OldRoot -.->|Signs| NewRootCert

    style OldRoot fill:#f9c,stroke:#333
    style NewRootTrust fill:#bfb,stroke:#333
    style NewRootCert fill:#fff,stroke:#333,stroke-dasharray: 5 5