EXERCISE 3 — The trust store, corporate inspection, and missing intermediates
==============================================================================

FINDING YOUR TRUST STORE (list installed root CAs):

  Linux (Debian/Ubuntu):
      ls /usr/share/ca-certificates/mozilla/
      awk -v cmd='openssl x509 -noout -subject' '/BEGIN/{c=cmd} {print | c}' \
          /etc/ssl/certs/ca-certificates.crt   # list every root's subject

  macOS:
      Keychain Access app > "System Roots" keychain, OR:
      security find-certificate -a -p /System/Library/Keychains/SystemRootCertificates.keychain

  Windows:
      certmgr.msc  > "Trusted Root Certification Authorities" > Certificates
      (or PowerShell: Get-ChildItem Cert:\LocalMachine\Root)

  Firefox ships its OWN store (independent of the OS):
      Settings > Privacy & Security > Certificates > View Certificates > Authorities

  You'll find a few hundred root CAs pre-installed. THIS LIST is the
  foundation of all HTTPS trust on the machine.

SCENARIO (a) — company installs its OWN root CA on employee laptops:
  - By adding a corporate root to each laptop's trust store, the company
    makes those machines trust certificates THE COMPANY issues.
  - A proxy/firewall can then perform a deliberate man-in-the-middle: it
    terminates the employee's TLS connection, presents a cert it generated
    on the fly (signed by the corporate root the laptop now trusts), and
    opens a second TLS connection to the real site. Because the laptop
    trusts the corporate root, no warning appears.
  - WHY IT WORKS: trust is just membership in the trust store — whoever
    controls that list controls what the machine trusts.
  - WHAT IT IMPLIES: anyone who can add a root to your trust store can
    transparently decrypt your HTTPS traffic. So (1) corporate networks can
    legitimately inspect traffic this way, and (2) you must guard your
    trust store — a malware-installed root is a total compromise of HTTPS.

SCENARIO (b) — server omits its intermediate certificate:
  - The chain the server sends is now incomplete: leaf, but no intermediate
    linking it to the root.
  - SOME clients SUCCEED: they may have cached the intermediate from a
    previous connection, or fetch it via the "AIA" URL embedded in the leaf
    (caIssuers), so they reconstruct the chain themselves.
  - OTHER clients FAIL: many (older browsers, mobile apps, curl, openssl)
    do NOT cache or fetch, so they can't bridge leaf->root and report
    "unable to get local issuer certificate."
  - This produces the classic "works on my laptop, fails on her phone" bug.
  - FIX: configure the server to send the FULL chain (leaf + intermediates)
    — the fullchain file. (Chapter 10 covers the server config.)