EXERCISE 1 — Dumping and reading the full certificate chain
============================================================

Command:
  openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

-showcerts prints EVERY certificate the server sent, not just the leaf.

You'll see numbered entries with their Subject (s:) and Issuer (i:), e.g.:

  Certificate chain
   0 s:CN=example.com
     i:C=US, O=DigiCert Inc, CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
   -----BEGIN CERTIFICATE----- ... (the LEAF) ...
   1 s:C=US, O=DigiCert Inc, CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
     i:C=US, O=DigiCert Inc, CN=DigiCert Global Root G2
   -----BEGIN CERTIFICATE----- ... (the INTERMEDIATE) ...

READING THE LINKS:
  - Cert 0 (leaf) Subject = CN=example.com,
            Issuer  = "...G2 TLS RSA SHA256 2020 CA1".
  - Cert 1 (intermediate) Subject = "...G2 TLS RSA SHA256 2020 CA1"
            -> EXACTLY equals cert 0's Issuer. The links match up:
               leaf.issuer == intermediate.subject.
  - Cert 1's Issuer = "DigiCert Global Root G2" -> the ROOT.

IS THE ROOT INCLUDED?
  - No. Typically the server sends only cert 0 (leaf) and cert 1
    (intermediate). The ROOT is NOT sent, because the client already has
    it in its trust store — sending it would be redundant (and a client
    wouldn't trust a root just because a server handed it over anyway).

WHY IT MATTERS:
  - Each "i:" of one cert should equal the "s:" of the next cert up. That
    is the chain. The browser verifies each leaf->intermediate->root
    signature, then checks the final root is in its trust store.
  - To verify a saved chain explicitly:
        openssl verify -CAfile root.pem -untrusted intermediate.pem leaf.pem
    -> prints "leaf.pem: OK" when the chain is complete and valid.