Concepts: Browser Security, Certificate Store & 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)

Certificate Validation — Before the TLS handshake completes, your browser walks the certificate chain (as we covered in Session 3). It checks that the chain leads to a trusted Root CA, that the certificate has not expired, that the domain matches, and that the certificate has not been revoked. This runs on every HTTPS connection, every time.

HSTS Enforcement (HTTP Strict Transport Security) — If you have ever visited a site that uses HSTS, your browser saved a note: “This site will only work over HTTPS. Never try HTTP.” When you visit that site again, your browser does not even attempt an HTTP connection. It starts with HTTPS directly. This protects against a class of attack where a network-level observer tries to downgrade your connection to unencrypted HTTP.

Mixed Content Blocking — An HTTPS page that loads one resource (an image, a script, a font) over plain HTTP has a problem: that one unencrypted resource could be intercepted and replaced by anyone on the network path. Your browser blocks it. This is why web developers sometimes see console warnings about “mixed content” — they have accidentally linked to an HTTP resource from an HTTPS page.

Security Warning UI — The error codes you see are not generic warnings. Each one means something specific:

NET::ERR_CERT_DATE_INVALID — certificate expired
NET::ERR_CERT_AUTHORITY_INVALID — issuer not in the trust list
NET::ERR_CERT_COMMON_NAME_INVALID — domain name mismatch
NET::ERR_CERT_REVOKED — certificate explicitly revoked

These are hard blocks. Your browser is not asking for your opinion. It is refusing to connect.

Deepa Asks

“Does the browser run these checks even for sites I’ve visited a hundred times?”

Yes, every single time. Certificate validity is checked on every connection because certificates expire, get revoked, and can change. There is no “trusted, skip the check” mode. This is why even a site you use daily will show an error if its certificate expires overnight.

The Browser Certificate Store

Here is a question Deepa asked: “Who decided that DigiCert is trustworthy?”

The answer is: Apple, Google, Microsoft, and Mozilla. Each of them maintains a certificate store — a list of Root CA certificates that are pre-installed on devices and browsers that ship on their platforms.

When you buy a new Android phone, it comes with approximately 150 Root CA certificates already installed. These are the authorities that Google has audited and approved. Your phone 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 sbi.co.in — not because someone told it SBI is trustworthy, but because SBI’s certificate was issued by DigiCert, and DigiCert is in the pre-installed trust store that Google put on your phone.

Viewing the Certificate Store on Your Device

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

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.

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

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

Rohan Goes Deeper

Firefox is unusual among browsers in that it maintains its own Root CA store rather than using the operating system’s. This means a certificate trusted by Chrome on Windows might not automatically be trusted by Firefox on the same machine. On Android and iOS, most browsers use the OS certificate store — except Firefox for Android, which uses Mozilla’s. This independence gives Mozilla direct control over which authorities it trusts, separate from decisions made by Apple or Google.

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.

Why HTTPS Alone Is Not Enough

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

Scenario	Encrypted?	Server Verified?	Safe?
HTTP only	No	No	No — all data visible on the path
HTTPS + unverified cert	Yes	No	Partially — encrypted but could be an impersonator
HTTPS + valid cert	Yes	Yes	Yes — encrypted AND correct server

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 sbi.co.in, validates the certificate, and the handshake succeeds, you know:

Your traffic is encrypted (no one on the path can read it)
You are connected to the actual SBI server (the certificate proves it)
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 Padlock Does Not Mean ‘Safe’

A padlock icon means the connection is encrypted. It does not mean the website is legitimate, trustworthy, or free from fraud. Any website can get an HTTPS certificate — including websites set up for fraudulent purposes. Always check the domain name in the address bar, not just the padlock. Encryption is about privacy in transit, not about the trustworthiness of the destination.

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.

Rohan Goes Deeper

HSTS has a feature called preloading. Major sites can submit their domain to a list that is compiled directly into browsers — so even on the very first visit, before the site has ever had a chance to send an HSTS header, the browser already knows to use HTTPS only. The HSTS preload list at hstspreload.org includes millions of domains. Banks and government sites are strongly encouraged to use it.

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.

Step 1 — Is the device connected to the network?
  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

Step 2 — Is DNS working?
  Test: ping a domain name (e.g., ping sbi.co.in) 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

Step 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

Step 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.

Deepa Asks

“What if the site loads fine but shows weird content?”

That is an application layer problem — Step 5, so to speak. The network is fine (all four steps above passed), but the server is returning unexpected data. This is a different kind of investigation — checking the server logs, looking at what the response actually contains, comparing with expected behaviour.

Key Takeaway

Your browser is not passive software that displays whatever it receives. It actively validates, blocks, and enforces. Understanding what it does — and what each error code means — turns browser warnings from scary red pages into specific, readable diagnostic information. Every NET::ERR_ code is telling you exactly what failed and at which step.

How the Internet Stays Safe