Hands-On: Hashing & Real Certificates

These exercises take you inside the hashing and certificate system — the same foundations your phone uses automatically every time you open a banking app.

Exercise 0 — Watch the Avalanche Effect Live

Before You Start: The avalanche effect means that a tiny change in input produces a completely different hash output. This exercise makes that concrete.

1. Open your phone’s browser and go to sha256.online
2. In the text input box, type: Hello
3. Click Hash (or the equivalent button)
4. Copy or note the hash output — a 64-character string
5. Now change the H to lowercase: hello
6. Click Hash again
7. Compare the two outputs

What You’re Seeing

Two inputs that differ by a single character — the capitalisation of one letter — produce completely different 64-character hashes. There is no similarity between them. This is the avalanche effect.

Now try this:

1. Type a full sentence: The quick brown fox
2. Hash it and note the output
3. Add a single period: The quick brown fox.
4. Hash again and compare

The addition of one character — a period — produces a completely different hash. This is why hashing is used to detect any modification to a document, a file, or a certificate. Even one changed character is instantly visible.

Discussion Prompt: Banks store the SHA-256 hash of your password, not the password itself. When you log in, the bank hashes what you typed and compares it to the stored hash. If they match, you are in. Why is this safer than storing the password directly? (Hint: think about what happens if the bank’s database is stolen.)

Exercise 1 — Read a Bank’s Certificate Chain

Before You Start: Every HTTPS site has a certificate chain going from the site’s certificate up to a Root CA. This exercise shows you how to read it.

1. Open Chrome on your phone and go to https://hdfcbank.com
2. Tap the padlock icon in the address bar
3. Tap “Certificate” or “Certificate is valid”
4. You are now looking at the site’s certificate. Note:
   • Subject / Common Name — what domain is this certificate for?
   • Issuer — which Intermediate CA issued this?
   • Validity — when does it expire?
5. Look for a way to navigate up the chain. In Chrome, you may see tabs or an “Issued by” link. In Firefox on desktop, you can see the full chain in Certificate Viewer
6. If your browser shows the chain, tap through to the Intermediate CA and then the Root CA

What You’re Seeing

You have just walked the same chain your browser walks every time you visit this site. The Root CA certificate at the top is embedded in your Android or iOS device, pre-installed by Google or Apple. Everything below it depends on that pre-established trust.

Compare what you see with the certificate fields table from the Concepts page: Subject, Issuer, Valid From/To, Public Key, Signature Algorithm, Thumbprint. All of these are real values in the real certificate you are reading.

Discussion Prompt: The HDFC Bank certificate expires on a specific date. What happens to every customer who tries to use net banking if the bank’s IT team forgets to renew it?

Exercise 2 — See What a Certificate Error Looks Like

Before You Start: badssl.com is a test site maintained specifically to demonstrate different certificate error states. It is safe to visit — these errors are intentional.

1. Open your browser and go to https://expired.badssl.com
2. Read the error message carefully — what does your browser say? Note the exact error code (it usually starts with NET::ERR_CERT_)
3. Look for the “Advanced” option and tap it — read the technical explanation your browser provides
4. Do not proceed to the site — go back instead
5. Go back and visit https://self-signed.badssl.com
6. Read this error message — how is it different from the expired certificate error?
7. Now visit https://wrong.host.badssl.com — what does this error mean?

What You’re Seeing

Each error represents a different failure in the certificate verification chain:

Notice that your browser does not just warn you — for these errors, it makes you go through extra steps to proceed at all. That is intentional. These are hard blocks, not suggestions.

Discussion Prompt: Which of these three certificate errors would a site accidentally have if its IT team simply forgot to renew the certificate? Which error is the most deliberate — most likely chosen intentionally?

Exercise 3 — Analyse a Certificate with SSL Labs

Before You Start: SSL Labs runs a detailed technical analysis of a site’s certificate and TLS configuration. This is the tool that security professionals use to audit sites.

1. Go to ssllabs.com/ssltest on your phone’s browser
2. In the hostname field, type sbi.co.in and tap Submit
3. Wait for the analysis to complete (60–90 seconds)
4. Look at the overall grade (A, A+, B, etc.)
5. Scroll to the Certificate section and find:
   • Subject — the domain name
   • Fingerprint — the SHA-256 hash (thumbprint) of this specific certificate
   • Issuer — the CA that signed it
   • Signature algorithm — how the signature was created
   • Key — what type and size is the public key?
6. Scroll to Protocol Details and find the HSTS field — note whether SBI uses it (we cover HSTS in Session 4)

What You’re Seeing

The certificate fingerprint is a SHA-256 hash — the exact same hash function you used in Exercise 0. If the certificate changes (even by one character), the fingerprint changes completely. You are seeing the avalanche effect applied to a real production certificate.

Discussion Prompt: SSL Labs shows the certificate’s expiry date. Should SBI be renewing this certificate automatically or manually? What are the risks of each approach?

Tying It Together

You now know the three foundations of digital trust — and you have seen all three in action:

• Hashing — creates a unique fingerprint for any data; changing one character changes everything (Exercise 0)
• Certificate chains — trust flows from Root CA to Intermediate to site; you walked the chain yourself (Exercise 1)
• Certificate errors — each error type represents a specific failure in the verification process (Exercise 2)
• Real-world analysis — SSL Labs shows the same fields we studied in the concepts page, on a real production site (Exercise 3)

Every time you do online banking, your phone does all of this automatically. Now you understand what it is doing and why. In Session 4, we look at the browser itself — not as software that displays pages, but as a security system enforcing policies on every connection you make.