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, and use SSL Labs to analyse a bank’s HTTPS configuration.

Exercise 1 — View 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

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 any entry to see its details: the CA’s own certificate, valid from/to dates, and its fingerprint

Deepa Asks

“I can see certificates I’ve never heard of — are these all safe?”

Yes. Every CA on the System tab has been vetted and approved by Google (for Android) or Apple (for iOS) through an auditing process. These are organisations that have met strict technical and procedural requirements. If any CA were found to be acting improperly, Google or Apple would remove it in the next system update.

On Chrome or 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 — same categories as on Android

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 — Certificate Errors in the Wild

Before You Start: badssl.com maintains test pages for different TLS error states. Each error demonstrates a specific failure mode. Read the exact error code your browser shows — that code tells you exactly what failed.

  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 your browser displays (look for something like NET::ERR_CERT_DATE_INVALID)
  4. Go back and visit https://self-signed.badssl.com
  5. Note the error code here — how is it different from the first one?
  6. Go back and visit https://wrong.host.badssl.com
  7. Note this error code too

What You’re Seeing

URLError Code (Chrome)Meaning
expired.badssl.comNET::ERR_CERT_DATE_INVALIDCertificate validity period has passed
self-signed.badssl.comNET::ERR_CERT_AUTHORITY_INVALIDIssuing CA not in the browser’s trust store
wrong.host.badssl.comNET::ERR_CERT_COMMON_NAME_INVALIDCertificate domain name does not match URL

Each error code is specific. Your browser is not saying “something is wrong” — it is saying exactly which step of certificate verification failed.

These Are Hard Blocks

On badssl.com, these errors are intentional. On any real site you want to use — especially for banking, government services, or anywhere you enter a password — do not click “Advanced → Proceed.” These error codes mean your browser cannot verify who you are talking to. Leave the site.

Extra exploration: After reading each error, click “Advanced” to see the extended explanation your browser provides. Notice how specific it is — this is the browser telling you exactly what it found and why it is refusing to continue.

Discussion Prompt: A bank’s certificate expires overnight. What does every customer see the next morning when they try to use net banking? What should the bank’s IT team have done to prevent this? (Hint: Let’s Encrypt sends renewal reminders 30 days before expiry and supports automated renewal.)

Exercise 3 — SSL Labs Analysis of sbi.co.in

Before You Start: SSL Labs is the industry-standard tool for analysing a site’s HTTPS configuration. Security teams at banks and large organisations use it to audit their own sites. You used it in Session 3 to look at the certificate — this time focus on the HSTS and security configuration sections.

  1. Go to ssllabs.com/ssltest on your browser
  2. In the hostname field, type sbi.co.in 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, note:

  • Subject and Issuer (does it match what you expect for a major bank?)
  • Fingerprint SHA-256 (this is the SHA-256 hash of the certificate — the same hash function from Session 3 Exercise 0)
  • Key type and size

In the Protocol Details section, look for:

  • Strict Transport Security (HSTS) — is it enabled? What is the max-age?
    • max-age=31536000 means “remember to always use HTTPS for this domain for one year”
    • Look for whether includeSubDomains and preload are set
  • TLS 1.3 — does the site support the current version?

What You’re Seeing

The HSTS status tells you whether SBI has instructed browsers to always use HTTPS. If HSTS is set with a long max-age, every browser that has visited the site will refuse to connect over HTTP for the duration of that period — even if someone on the network tries to redirect them.

Rohan Goes Deeper

The SSL Labs grade combines many factors: supported TLS versions (older versions like TLS 1.0 and 1.1 lose points), cipher strength, whether forward secrecy is supported, HSTS configuration, and certificate properties. An A+ grade requires valid certificate + TLS 1.2 or 1.3 only + HSTS enabled. An A grade is good. A B grade means something is misconfigured. C or below means serious issues.

Discussion Prompt: Compare the SSL Labs grade for sbi.co.in 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 three 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 errors — you read the exact error codes for three failure modes (Exercise 2)
  3. HSTS and TLS configuration — you used SSL Labs to read a real bank’s security configuration (Exercise 3)

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.