Guides

Cryptography, TLS, Certificates and PKI in Practice

By Ravindra Bagale, Cyber Security trainer · LinkedIn · Published: 29 September 2026 · Last updated: 30 September 2026

Cryptography in practice is less about clever puzzles and more about daily habits: hashing for integrity and password storage, encryption for confidentiality, and TLS certificates issued through a PKI so browsers know they reached the right server. This guide stays on defender and builder basics — no cryptanalysis attack recipes.

Hash: data → fingerprint (not secret storage of the original)
Encrypt: data + key → ciphertext (key management is the hard part)
TLS: HTTPS padlock = encrypted path + identity check via cert chain
PKI: who signed that cert, and do we trust the signer?

What do I need before this guide?

• Idea of HTTP vs HTTPS and why port 443 appears in server configs.
• Optional: Free SSL with Certbot, Wireshark for defenders.

How do hashing, encryption, TLS and PKI fit together?

1. Hashing — same input → same digest; tiny change → different digest. Used for file integrity checks and (with salt + slow KDF) password storage.
2. Symmetric encryption — one shared key encrypts and decrypts (fast for disks and TLS session keys).
3. Asymmetric encryption / signatures — key pairs; private key signs or decrypts, public key verifies or encrypts to you.
4. Certificates — bind a public key to a name (example.com) with a CA signature.
5. TLS — handshake agrees algorithms and keys; then application data rides encrypted.
6. PKI — the web of trust anchors your OS/browser ships so it can validate leaf certificates.

How does a certificate prove “right server”?

Vertical story:

1. Browser connects to https://example.com.
2. Server presents a leaf certificate stating “public key for example.com”.
3. Browser checks signatures up the chain to a trusted root.
4. Browser checks name match, expiry, revocation signals (as implemented).
5. Only then does the padlock story complete for users.
6. Self-signed lab certs are fine on your lab with an explicit trust decision — not for public customers.

Real incident: Equifax (2017) — patching and trust failures at scale

Public reporting on the Equifax breach (2017) described attackers exploiting an unpatched web framework path and a long, painful exposure of personal data. Crypto and TLS were part of the wider lesson set for the industry: encrypt sensitive data, patch internet-facing stacks fast, and treat certificate / secret handling as operational work — not a one-time slide.

Takeaways (vertical):

1. What happened (theme) — massive personal-data breach with multi-year trust fallout.
2. Care-take — patch internet-facing apps on a measured SLA.
3. Care-take — encryption at rest and in transit still need key and access control.
4. Care-take — inventory where personal data lives before the auditor asks.
5. Care-take — expired or mis-issued certificates cause outages; monitor expiry.
6. Not in this guide — exploit details for any CVE.

Red Team vs Blue Team (awareness only)

Red Team — what attackers try (high-level)

• Phish users onto lookalike domains with “valid” certs on the wrong brand name.
• Steal private keys or TLS termination configs from mismanaged servers.
• Downgrade users to clear HTTP when mixed content or redirects fail.

Blue Team — defend, detect, respond

• HSTS, correct redirects, automated cert renewal (Certbot-class tooling).
• Protect private keys; restrict who can download them.
• Monitor cert expiry; inventory SANs.
• Store passwords with modern hashing (never reversible encryption for passwords).

How do I apply crypto safely step by step?

Step 1 — Separate the three words

1. Say out loud: hash ≠ encrypt ≠ encode (Base64 is encoding, not security).
2. Write one example of each in your notebook.

Step 2 — HTTPS on something you own

1. Point a lab domain or use Certbot on your EC2 lab (Certbot guide).
2. Confirm padlock; fix HTTP→HTTPS redirect.
3. Check expiry date; run a dry-run renew if using Let’s Encrypt.

Step 3 — Password storage mindset (builders)

1. Use the framework’s recommended password hasher.
2. Never log raw passwords.
3. Unique salts; reject broken legacy schemes for new apps.

Step 4 — Key and cert hygiene

1. Private keys: restricted filesystem permissions; not in git.
2. Rotate when people with access leave.
3. Lab self-signed: document that browsers will warn — expected.

Step 5 — Read TLS with a defender lens

1. In a sample PCAP, find Client Hello / SNI (Wireshark guide).
2. Confirm you understand why payloads look opaque.
3. Do not disable validation in production clients.

Step 6 — Careful with “crypto” products

1. Prefer boring, maintained libraries over viral GitHub ciphers.
2. Full-disk encryption + strong login beats a homemade notepad cipher.
3. VPN and TLS stack with MFA — layers again.

What should builders remember about libraries?

Vertical “boring is good” list:

1. Use TLS libraries and HTTPS servers that your OS vendor still patches.
2. Prefer framework password helpers over copy-pasted hash snippets from random blogs.
3. Pin dependency versions thoughtfully; watch security advisories.
4. Do not ship verify=False or custom “trust all certs” helpers in client apps.
5. Document where private keys live for every service you run in lab or prod.
6. When a certificate warning appears on a real banking site, stop — do not click through.

Care-take — everyday crypto discipline

1. HTTPS everywhere you host.
2. Inventory certificates and expiry calendars.
3. MFA on registrars and CA accounts.
4. No private keys in screenshots or tickets.
5. Teach family: ignore scary “install this root CA” pop-ups on random sites.
6. Pair with backups — ransomware does not care that your TLS was perfect.

How do I fix common crypto / TLS mistakes?

Ghabru naka 😅 — these are the usual ones: