Challenge 2: What OCSP Stapling Actually Solves — Solution
Walkthrough

The problem it solves:

Checking whether a certificate has been revoked requires contacting
the certificate authority's OCSP responder. Without stapling, that
check is the CLIENT's own job -- the visitor's browser itself makes a
separate, live network request to the CA every time it connects to
the site. This has two real costs: it adds latency (an extra
round-trip, and a real one, not a cached local check), and it leaks
information to the CA about which sites a given client is visiting,
since the CA sees a fresh request for every connection.

What changes once stapling is enabled:

The SERVER, not the client, becomes the one contacting the CA. Apache
periodically fetches a signed, time-stamped proof of the
certificate's current status from the CA on its own schedule --
cached and refreshed periodically, not for every individual client
connection. When a client connects, Apache attaches ("staples") that
already-fetched proof directly into the TLS handshake itself. The
client still gets proof the certificate hasn't been revoked, but it
never has to contact the CA on its own, and the CA never sees that
specific client's individual connection at all -- only the server's
own periodic refresh requests.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the reader can name both real benefits
(performance and privacy) and specifically identify who is doing the
contacting before vs. after stapling is enabled -- the actual
mechanism change, not just "it makes things faster."