Challenge 2: Certificate Warnings Despite an On-Time Renewal --
Solution Walkthrough

What almost certainly went wrong: installing a renewed certificate
into the Windows Certificate Store creates a brand-new certificate
object with its own new thumbprint -- even though it's for the exact
same hostname, it is not treated as an in-place update of the old
one. The site's existing HTTPS binding still references the old
certificate's original thumbprint, which was never changed. Because
of this, IIS kept presenting the old certificate the entire time --
right up until it actually expired on the expiration date, which is
exactly when visitors started seeing warnings, since that's when the
still-bound old certificate finally became genuinely invalid.

The step that was missed: after installing the new certificate into
the store, someone needed to explicitly update the site's HTTPS
binding to reference the new certificate's thumbprint instead of the
old one. Simply installing a renewed certificate into the store does
nothing to any existing binding still pointing at the prior
thumbprint -- the two are separate steps, and only the first one was
done here.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the reader recognizes the chapter's own
named renewal gotcha in a realistic scenario -- specifically that a
new thumbprint from renewal requires a separate, explicit binding
update, and that skipping it produces a delayed failure (warnings
appearing only at the original expiration date, not immediately after
"renewal").