Hands-On: Inspect Your Browser’s Security

These exercises take you inside the security mechanisms your browser runs automatically. You will look at your device’s certificate store, encounter real certificate errors, check HSTS status, and use SSL Labs to analyse a bank’s HTTPS configuration.

Exercise 1 — Open Your Device’s Certificate Store

Before You Start: Your device came with approximately 150 Root CA certificates pre-installed. These are the authorities your device unconditionally trusts. This exercise shows you who they are.

On Android:

1. Open Settings
2. Go to Security (or Security & Privacy on newer Android versions)
3. Tap Encryption & Credentials
4. Tap Trusted Credentials
5. Make sure you are on the System tab (not User)
6. Scroll through the list — these are all the Root CAs pre-installed by Google on your device

On Chrome/Edge (desktop):

1. Open Settings → Privacy and Security → Security
2. Scroll to Manage Certificates
3. Go to the Trusted Root Certification Authorities tab
4. Browse the list

On Firefox (desktop):

1. Open Settings → Privacy & Security
2. Scroll to Certificates → View Certificates
3. Go to the Authorities tab
4. Note: Firefox maintains its own store, independent of the OS

On Windows (system-wide):

1. Press Win + R
2. Type certmgr.msc and press Enter
3. Expand Trusted Root Certification Authorities → Certificates

What to look for:

• Find DigiCert — this is one of the CAs that issues certificates for many Indian banks
• Find ISRG Root X1 — this is Let’s Encrypt’s root CA, used by millions of websites
• Tap or click any entry to see its details: the CA’s own certificate, valid from/to dates, and its fingerprint

Discussion Prompt: You see around 150 Root CAs on your Android phone. Any one of them could technically issue a certificate for any domain. Why is this not a security problem in practice? (Hint: think about what happens to a CA that issues a fraudulent certificate.)

Exercise 2 — Read onlinesbi.sbi’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 on a real banking site.

1. Open Chrome on your phone and go to https://onlinesbi.sbi
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 CA issued this?
   • Validity — when does it expire?
5. Navigate up the chain — look for an “Issued by” link or chain view
6. Follow the chain from the site certificate → Intermediate CA → Root CA
7. Note the Root CA name — this is the authority at the top of the chain

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.

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

Exercise 3 — Certificate Errors with badssl.com

Before You Start: badssl.com maintains test pages for different TLS error states. Each error demonstrates a specific failure mode. Match each error to what you learned in the Concepts page.

1. Open your browser and go to https://expired.badssl.com
2. Do not click through — read the warning page carefully
3. Note the exact error code: NET::ERR_CERT_DATE_INVALID
   • Match: Certificate expired. The server forgot to renew.
4. Go back and visit https://self-signed.badssl.com
5. Note the error code: NET::ERR_CERT_AUTHORITY_INVALID
   • Match: Signed by a CA your browser does not trust. Could be self-signed or intercepted.
6. Go back and visit https://wrong.host.badssl.com
7. Note the error code: NET::ERR_CERT_COMMON_NAME_INVALID
   • Match: Domain on certificate does not match URL. You may be talking to the wrong server.

Discussion Prompt: Which of these three errors would a bank accidentally have if its IT team forgot to renew? Which is the most suspicious — the one most likely to indicate someone intercepting your connection?

Exercise 4 — Check HSTS Status

Before You Start: HSTS tells your browser to always use HTTPS for a domain. You can check which domains have registered HSTS in your browser.

1. Open Chrome on your laptop or desktop
2. In the address bar, type: chrome://net-internals/#hsts
3. In the Query HSTS/PKP domain section, type gmail.com and click Query
4. Read the result — you should see an entry with static_upgrade_mode: FORCE_HTTPS
5. Now query onlinesbi.sbi — does it have an HSTS entry?
6. Query a random small website you know — does it have HSTS?

What You’re Seeing

Domains that show FORCE_HTTPS will never be loaded over HTTP by your browser. Gmail is on the HSTS preload list — hardcoded into Chrome’s source code — so even a fresh browser that has never visited Gmail enforces HTTPS for it. Smaller sites may not use HSTS at all, which means they rely on the user typing https:// or on redirects.

Discussion Prompt: If a site is on the HSTS preload list, what happens if someone on a public Wi-Fi network tries to redirect you to the HTTP version of that site?

Exercise 5 — SSL Labs Deep Analysis

Before You Start: SSL Labs gives a comprehensive grade for a site’s HTTPS configuration. This time, focus on the certificate chain and HSTS details.

1. Go to ssllabs.com/ssltest on your browser
2. In the hostname field, type onlinesbi.sbi and tap Submit
3. Wait 60–90 seconds for the analysis to complete
4. Note the overall grade (A, A+, B, etc.)

In the Certificate section, find:

• Subject and Issuer — who issued SBI’s certificate?
• Certificate chain — can you see the Intermediate and Root CA?
• Expiry date — when does the current certificate expire?

In the Protocol Details section, look for:

• Strict Transport Security (HSTS) — is it enabled? What is the max-age?
• TLS 1.3 — does the site support the current version?

What You’re Seeing

The SSL Labs grade combines certificate validity, TLS version support, cipher strength, and HSTS configuration. An A+ requires all of these to be correctly configured. The certificate chain you see here is the same chain your browser walks automatically on every connection.

Discussion Prompt: Compare the SSL Labs grade for onlinesbi.sbi with ssllabs.com (Qualys’s own site). What differences do you notice in their HSTS and TLS configurations?

Tying It Together

You have now seen the browser security mechanisms from the Concepts page, in action:

1. Certificate Store — you viewed the ~150 Root CAs your device trusts (Exercise 1)
2. Certificate chain — you walked onlinesbi.sbi’s chain from site cert to Root CA (Exercise 2)
3. Certificate errors — you read the exact error codes for three failure modes and matched them to concepts (Exercise 3)
4. HSTS — you queried real domains to see which ones enforce HTTPS (Exercise 4)
5. SSL Labs analysis — you read a real bank’s security configuration and certificate chain (Exercise 5)

Every connection your browser makes runs some version of these checks automatically. You just made them visible.

In Session 5, we put all five sessions together — tracing a complete connection from DNS lookup through certificate validation and HSTS enforcement, step by step, explaining which session taught each part.