The Complete Guide to SSL/TLS, Cryptography & Network Security

A common question developers ask when working with HTTPS and certificates is:

“If a fake server steals my public SSL Certificate, replaces my Public Key with their own Public Key, and sends it to a browser… won’t Let’s Encrypt validate it, allowing the hacker to decrypt user data?”

The Short Answer: No, this is mathematically impossible.

An SSL Certificate is not just a plain text file—it is packaged inside an immutable digital envelope stamped with an un-forgeable mathematical seal.

1. Wall #1: Digital Signatures & The Immutable Envelope

When Let’s Encrypt issues your certificate for blog.prashantlabs.com, it packages your domain name and your Public Key into a single data payload:

Certificate Package = [ Domain: blog.prashantlabs.com + YOUR Public Key ]

Let’s Encrypt hashes this data and encrypts the hash using Let’s Encrypt’s secret Private Key. This generates a Digital Signature attached to the bottom of your certificate.

What happens if a hacker alters the Public Key?

1. The hacker steals your certificate file and replaces YOUR Public Key with THEIR Public Key.
2. The hacker sends this tampered certificate to a visitor’s browser.
3. The visitor’s browser decrypts the Digital Signature using Let’s Encrypt’s Public Key (which is built into every operating system and browser).
4. The browser calculates the hash of the received certificate data.
5. HASH MISMATCH! Changing even 1 bit of the Public Key alters the calculated hash. The browser realizes the certificate was tampered with.
6. The browser immediately aborts the connection and displays NET::ERR_CERT_DATE_INVALID or Your connection is not private.

2. Wall #2: Why Using your Unmodified Certificate Fails

Suppose the hacker realizes they cannot alter the certificate, so they send your exact, unmodified SSL Certificate (containing your domain and YOUR real Public Key) to the victim’s browser.

Here is the exact sequence of what happens during the TLS Handshake:

3. Asymmetric vs Symmetric Encryption Explained

HTTPS uses a Hybrid Cryptosystem combining both Symmetric and Asymmetric encryption.

A. Symmetric Encryption (Single Key)

Both the sender and receiver share the exact same secret key to encrypt and decrypt messages.

• Analogy: A physical lockbox with two identical physical keys.
• Algorithms: AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305.
• Pros: Blazing fast! Requires very little CPU power (encrypts gigabytes per second).
• Cons: The Distribution Problem. How do you send the secret key to a stranger across the internet without eavesdroppers intercepting it?

B. Asymmetric Encryption (Public + Private Key Pair)

Uses two mathematically linked keys:

• Public Key: Shared publicly with the whole world. Used ONLY to encrypt data.

• Private Key: Kept 100% secret on your server. Used ONLY to decrypt data.

• Analogy: A street mailbox. Anyone can drop a letter through the slot (Public Key), but only the mail carrier with the physical key (Private Key) can open the back door to read it.

• Algorithms: RSA-4096, ECDSA, Ed25519.

• Pros: No secret key ever needs to be transmitted across the network!

• Cons: Computationally Slow. Takes ~100x more CPU cycles than symmetric ciphers.

4. Step-by-Step TLS 1.3 Handshake Breakdown

5. Real-World Attack Scenarios & Why They Fail

Scenario A: Rogue Public Wi-Fi Router (Coffee Shop Hacker)

• Attack: You connect to a malicious Wi-Fi router at a coffee shop (Free_WiFi). The hacker attempts to inspect your HTTP traffic.
• Why it Fails: The router only sees encrypted binary packets. Without your server’s Private Key, the hacker cannot decrypt the payload.

Scenario B: DNS Poisoning / Spoofing

• Attack: A hacker tampers with DNS so blog.prashantlabs.com points to the hacker’s IP address (192.0.2.50).
• Why it Fails: When the browser connects to the fake IP, the hacker’s server must present a valid SSL Certificate.
  • Self-signed cert -> Browser blocks with NET::ERR_CERT_AUTHORITY_INVALID.
  • Real stolen cert -> Hacker lacks the Private Key, handshake fails.

Scenario C: Stealing the .crt Public Certificate File

• Attack: A hacker finds a copy of your public .crt file on GitHub or from a network trace.
• Why it Fails: The .crt file contains only your Public Key. Possessing a Public Key gives the hacker zero ability to decrypt traffic sent to that key. Only the Private Key (stored securely on your server) can decrypt data.

6. Hands-On NGINX Setup & Auto-Renewal

sudo apt update
sudo apt install certbot python3-certbot-nginx -y

sudo certbot --nginx -d blog.prashantlabs.com --agree-tos --email admin@prashantlabs.com

server {
    listen 80;
    listen [::]:80;
    server_name blog.prashantlabs.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name blog.prashantlabs.com;

    ssl_certificate /etc/letsencrypt/live/blog.prashantlabs.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/blog.prashantlabs.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;

    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/letsencrypt/live/blog.prashantlabs.com/chain.pem;

    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;

    location / {
        proxy_pass http://127.0.0.1:4321;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto https;
    }
}

sudo certbot renew --dry-run

7. Security Summary Cheat Sheet