EXERCISE 3 — Browser cert viewer + three rejection scenarios
=============================================================

VIEWING IN THE BROWSER:
  - Click the padlock in the address bar > "Connection is secure" >
    "Certificate is valid" (Chrome/Edge) or the padlock > "More
    information" > "View Certificate" (Firefox).
  - You'll see the SAME X.509 fields openssl showed: Issued To (Subject /
    SAN), Issued By (Issuer), Validity period, public key info, and the
    chain (leaf -> intermediate -> root, which is Chapter 5).

THREE REJECTION SCENARIOS — which check fails:

(1) Expired certificate.
    CHECK THAT FAILS: Validity (Not After date).
    The current date is past "Not After", so the cert is out of its valid
    window. Browser error: NET::ERR_CERT_DATE_INVALID. (A not-yet-valid
    cert, current date before "Not Before", fails the same validity check.)

(2) Cert whose SAN doesn't include the visited domain.
    CHECK THAT FAILS: hostname / SAN matching.
    The cert is genuine and in-date, but the domain you typed isn't in its
    Subject Alternative Name list, so it isn't valid FOR THIS site. Error:
    NET::ERR_CERT_COMMON_NAME_INVALID. This is the impersonation defence:
    an attacker's real cert for their own domain won't match your bank's
    hostname.

(3) Cert with one data field altered after signing.
    CHECK THAT FAILS: signature verification.
    The CA signed a hash of the original fields. Changing any field (e.g.
    swapping in the attacker's public key, or editing the SAN) makes the
    recomputed hash differ from the signed one, so the signature no longer
    verifies against the CA's public key. The cert is rejected as
    tampered/invalid — exactly the hash-then-sign protection from Ch. 2.

SUMMARY — the browser runs all of these, and ALL must pass:
    in date? (validity)  +  name matches? (SAN)  +  signature valid &
    chains to a trusted CA? (signature + Chapter 5 trust chain)