Challenge 1: Thumbprint vs. File Path -- Solution Walkthrough

Apache and Nginx both expect a certificate and its private key to be
loose files sitting somewhere on disk, referenced directly by a
config directive pointing at a file path (SSLCertificateFile/
SSLCertificateKeyFile for Apache, ssl_certificate/ssl_certificate_key
for Nginx). IIS's model is different: a certificate has to already
be installed into the Windows Certificate Store -- an OS-level
facility for managing certificates and their private keys, separate
from any web server's own configuration files -- before IIS can use
it at all. Once installed, IIS's own binding configuration
references that certificate purely by its thumbprint, a SHA-1 hash
that uniquely identifies that specific certificate entry in the
store.

What this means for the private key: it never has to exist as a
plaintext file anywhere IIS's own configuration touches. The Windows
Certificate Store manages the key material itself, with its own
separate access-control and export permissions, independent of
web.config or applicationHost.config entirely. A binding pointing at
a thumbprint is really just telling IIS "use whichever certificate
the OS already has installed under this fingerprint" -- the actual
key material stays managed by the OS-level store rather than sitting
in a file IIS's own configuration directly names.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the reader understands this as a genuine
architectural difference in where trust/key material lives -- not
just a different syntax for specifying the same kind of file
reference Apache and Nginx use.