EXERCISE 2 — Extracting specific fields, and why SAN matters
=============================================================

Save the cert once, then query individual fields:
  openssl s_client -connect example.com:443 -servername example.com </dev/null \
    | openssl x509 -out cert.pem

Targeted field extraction:
  openssl x509 -in cert.pem -noout -subject
      subject=CN=example.com

  openssl x509 -in cert.pem -noout -issuer
      issuer=C=US, O=DigiCert Inc, CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1

  openssl x509 -in cert.pem -noout -dates
      notBefore=Jan  1 00:00:00 2025 GMT
      notAfter=Apr  1 23:59:59 2025 GMT

  openssl x509 -in cert.pem -noout -ext subjectAltName
      X509v3 Subject Alternative Name:
          DNS:example.com, DNS:www.example.com

  (Handy combo: -subject -issuer -dates all at once, or -fingerprint for
   the cert's hash, or -serial for the serial number.)

WHY THE BROWSER CHECKS SAN, NOT COMMON NAME:
  - When you visit https://www.example.com the browser must answer: "is
    this cert valid FOR THIS hostname?" It does so by checking whether
    www.example.com appears in the SAN list.
  - The Common Name (CN) inside Subject is a single free-text field and is
    now IGNORED for hostname matching by all modern browsers (deprecated
    for this purpose since ~2017). Relying on CN was ambiguous and couldn't
    list multiple names.
  - SAN is the standardized, multi-valued extension built for exactly this:
    it can list many domains and wildcards (e.g. *.example.com) in one cert.
  - So a cert that names the domain ONLY in CN (empty/mismatched SAN) is
    rejected as NET::ERR_CERT_COMMON_NAME_INVALID even though a human can
    "see" the right name in CN.

  Rule of thumb: CN is legacy/cosmetic; SAN is what's enforced.