Concepts: Certificate Store, HSTS, Mixed Content, Security Warnings, Troubleshooting

Your Browser Is a Security System

Deepa had assumed her browser’s job was to display pages. After this session, she will see it differently.

Every time you make an HTTPS request, your browser runs four security mechanisms automatically — before you see a single pixel of the page:

You type a URL and press Enter
         ↓
1. Certificate Validation
   Does this server have a valid cert from a trusted CA?
   If no → hard block, error page shown
         ↓
2. HSTS Check
   Has this site previously said "always use HTTPS"?
   If yes → browser refuses to downgrade to HTTP
         ↓
3. Mixed Content Check
   Does an HTTPS page try to load any HTTP resources?
   If yes → those resources are blocked
         ↓
4. Security Warning UI
   If anything failed in steps 1–3 → specific error code shown
   These are not suggestions — they are hard blocks
         ↓
Page loads (or does not)

The Browser Certificate Store

Here is something that surprised Deepa: she had no idea her phone came with a list of authorities it already trusts. She had never opened it, never configured it, never even knew it existed. But that list is the reason her browser can tell the difference between the real SBI website and a fake one.

Every browser and operating system ships with approximately 150 trusted Root CA certificates pre-installed. These are the authorities that the platform provider — Google for Android, Apple for iOS, Microsoft for Windows — has audited and approved. Your device trusts any certificate whose chain traces back to one of these pre-installed roots.

Your Android phone's certificate store (pre-installed by Google)
  ├── DigiCert Global Root G2
  ├── DigiCert Global Root CA
  ├── Let's Encrypt ISRG Root X1
  ├── Sectigo (formerly Comodo)
  ├── GlobalSign Root CA
  ├── Amazon Root CA 1
  ├── ... (~150 total)

This is why your phone trusts onlinesbi.sbi — not because someone told it SBI is trustworthy, but because SBI’s certificate was issued by a CA like DigiCert, and DigiCert is in the pre-installed trust store that Google put on your phone.

When your browser receives a server certificate, it walks the chain to find a matching root. Match found — connection proceeds. No match — you see the red warning screen.

Viewing the Certificate Store on Your Device

Chrome/Edge on desktop: Settings → Privacy and Security → Security → Manage Certificates → Trusted Root Certification Authorities

Firefox on desktop: Settings → Privacy & Security → View Certificates → Authorities tab (Firefox maintains its own certificate store, independent of the operating system!)

Windows: Win + R → certmgr.msc → Trusted Root Certification Authorities

Android: Settings → Security → Encryption & Credentials → Trusted Credentials

You will see a long list of Root CAs. Scroll through it. Find DigiCert or Let’s Encrypt. These are the authorities whose certificates are installed on your device — the ones your phone trusts unconditionally.

What Happens if a Root CA Is Removed?

If a Root CA is found to have issued certificates improperly — this has happened with several CAs over the years — it gets removed from the trust store. Once removed, every certificate it ever issued instantly stops being trusted by any browser or device that updates its store. Millions of sites could lose their certificate validity overnight. This accountability is what keeps CAs careful.

HSTS — HTTP Strict Transport Security

HSTS is a simple but powerful instruction from a server to your browser: “Never connect to me over plain HTTP — ever.”

When you visit a site that uses HSTS, the server’s response includes a header like this:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

This tells your browser: “For the next year (31,536,000 seconds), never connect to this domain or any of its subdomains over plain HTTP. Always use HTTPS.”

Your browser stores this instruction locally. On every subsequent visit, it enforces HTTPS before even making a network request. The browser does not try HTTP and then upgrade — it goes straight to HTTPS without any round trip.

Try it yourself: type http://onlinesbi.sbi into your browser. Watch what happens. The browser silently upgrades the connection to HTTPS. You never see the HTTP version. The upgrade happens inside the browser, before any request leaves your device.

How to check HSTS status: In Chrome, go to chrome://net-internals/#hsts. Type a domain like gmail.com or onlinesbi.sbi and click Query. You will see whether the domain has an HSTS entry and what its expiry is. Try a random small website — it probably will not have one.

Mixed Content Blocking

An HTTPS page is encrypted. Every resource it loads — images, scripts, stylesheets, fonts — should also be loaded over HTTPS. But what happens if an HTTPS page accidentally loads one resource over plain HTTP?

That one unencrypted resource breaks the security guarantee. An attacker who can see network traffic (someone on the same Wi-Fi, an ISP, a compromised router) could intercept that HTTP resource and replace it. They could inject malicious JavaScript, steal cookies, or modify what the page displays — all while the padlock icon still shows in the address bar.

Example: Imagine SBI’s online banking page is served over HTTPS, but the page accidentally loads the SBI logo image over http:// instead of https://. An attacker on the network intercepts the logo request and replaces the image with a fake one — or worse, replaces it with a script tag that steals session cookies. The rest of the page is encrypted, but that one HTTP resource is the crack in the wall.

Your browser prevents this. When an HTTPS page tries to load a resource over HTTP, the browser blocks it. The logo does not appear. The script does not run. The page may look broken — but the browser is protecting you.

Students sometimes see a missing image or a broken page and think something is wrong with the website. Often, it is the browser blocking mixed content — and that is the browser doing its job.

How to see mixed content warnings: Open DevTools (press F12 or Ctrl+Shift+I), go to the Console tab, and look for yellow or red warnings that say “Mixed Content.” These warnings tell you exactly which resource the browser blocked and why.

Browser Security Warnings — What Each Error Means

Most students see a red warning screen, panic, and click “Back to Safety” without knowing why. That is the right instinct — but understanding what each error means turns fear into knowledge. Each error code tells you exactly which step of certificate verification failed.

NET::ERR_CERT_DATE_INVALID

What it means: The certificate has expired. The server’s IT team forgot to renew it.

Is it dangerous? Not necessarily malicious — but you cannot verify the server’s identity with an expired certificate. It is like someone showing you an ID card that expired last month. Probably still them. But you cannot be sure.

NET::ERR_CERT_AUTHORITY_INVALID

What it means: The certificate was signed by a CA that your browser does not trust. This could be a self-signed certificate (the server created its own certificate with no CA involved) or it could be someone intercepting your connection and presenting their own certificate.

Is it dangerous? Potentially very. Self-signed certificates are common on internal development servers, but on a public website this means no trusted third party has verified the server’s identity. On a banking site, this should alarm you.

NET::ERR_CERT_COMMON_NAME_INVALID

What it means: The domain name on the certificate does not match the URL in your address bar. You may be talking to the wrong server.

Is it dangerous? Take this one seriously. If you typed onlinesbi.sbi but the certificate says someothersite.com, something is wrong. This could mean a misconfigured server, but it could also mean your connection has been redirected to a different server entirely.

Rajan bhaiya’s lesson: If Rajan bhaiya had noticed a COMMON_NAME_INVALID warning when he clicked that link in the email, he might have realised he was not on the real website — and he might have avoided the attack that cost him ₹50,000 and every file on his computer.

NET::ERR_CERT_REVOKED

What it means: The certificate was cancelled before its expiry date, usually because the server’s private key was compromised. The CA has explicitly revoked trust in this certificate.

Is it dangerous? Yes. Do not proceed. A revoked certificate means the CA has reason to believe the certificate can no longer be trusted. This is the digital equivalent of a government cancelling someone’s passport.

Hands-On Reference

Visit badssl.com to see these errors safely:

• expired.badssl.com — triggers NET::ERR_CERT_DATE_INVALID
• self-signed.badssl.com — triggers NET::ERR_CERT_AUTHORITY_INVALID
• wrong.host.badssl.com — triggers NET::ERR_CERT_COMMON_NAME_INVALID

Read the exact error code. Click “Advanced” to see the extended explanation. Match each error to the descriptions above.

Why HTTPS Alone Is Not Enough

This is a nuance that matters. HTTPS is necessary but not sufficient. Here is why:

The middle row is the key: you can have an encrypted connection to the wrong server. Encryption protects the channel; the certificate protects the identity. You need both.

A certificate proves that you are talking to the real server — not just that the connection is encrypted. If your browser connects to onlinesbi.sbi, validates the certificate, and the handshake succeeds, you know:

1. Your traffic is encrypted (no one on the path can read it)
2. You are connected to the actual SBI server (the certificate proves it)
3. The certificate has not been tampered with (the CA’s signature and the hash verify this)

If any one of these three things were missing, HTTPS would not be giving you what you think.

The same principles apply to UPI apps — your PIN is never transmitted, the connection uses TLS, and the app verifies the server certificate.

What Your Browser Does When You Visit a Banking Site

Let us trace exactly what happens, step by step, when Sunita didi opens her bank’s internal portal at work.

Step 1 — DNS Resolution
  Browser asks: "What is the IP for netbanking.example-bank.co.in?"
  DNS resolver returns: 203.x.x.x

Step 2 — TCP Connection + TLS Handshake
  Browser connects to 203.x.x.x on port 443
  Server presents its certificate

Step 3 — Certificate Validation
  Browser verifies the certificate chain
  Checks: valid CA? → expiry? → domain match? → revoked?
  All pass → TLS handshake completes

Step 4 — Session Key Established
  Symmetric session key agreed
  All data now encrypted with this key

Step 5 — HSTS Check
  Browser checks: "Has this site registered an HSTS policy?"
  If yes → browser saves: "always use HTTPS for this domain"
  Future visits skip any HTTP attempt entirely

Every step is automatic. Sunita didi does not press any button to make this happen. But she knows exactly what is happening — and when a step fails (a certificate error, a DNS failure, a connection refused), she knows which layer to look at.

Network Troubleshooting — Thinking in Layers

Sunita didi has a mental script she runs through on support calls. It mirrors the internet’s layered architecture. When something does not work, she does not guess — she eliminates layers.

Layer 1 — Is the device connected to the network? (ping / IP)
  Test: ping an IP address directly (e.g., ping 8.8.8.8)
  If this works: physical and network layers are fine
  If this fails: check Wi-Fi or cable connection

Layer 2 — Is DNS working?
  Test: ping a domain name (e.g., ping onlinesbi.sbi) or run nslookup
  If ping-by-name fails but ping-by-IP works: DNS is the problem
  Fix: check DNS server settings, try a different DNS server

Layer 3 — Is port 443 reachable?
  Test: try to connect to the site on port 443
  If DNS works but HTTPS fails: firewall or port block
  Look for: corporate firewall, ISP filtering, server down

Layer 4 — Is the TLS certificate valid?
  Test: visit the site and check for certificate errors
  If the connection works but shows a cert error: certificate issue
  Read the exact error code — it tells you which part of validation failed

Thinking in layers prevents the most common troubleshooting mistake: jumping to conclusions. “The internet is broken” is almost never true. Something specific at a specific layer is broken. The layers tell you where to look.