entra1-8  Exercise 2: Expired SAML Signing Certificate
=========================================================

Source: Microsoft Learn, "Tutorial: Manage federation certificates". Re-check
before relying on any detail; portal wording changes.

SITUATION
  Contoso's SAML signing certificate expired on 28 September. There is also an
  Inactive certificate expiring in 2029, created in August. Our product's SAML
  settings can hold only one signing certificate at a time.

ANALYSIS
  - Microsoft: if an expired certificate and an inactive valid one both exist,
    Entra uses the valid certificate automatically, and users may experience
    an outage if the application hasn't been given the new one. That fits the
    symptom: sign-in is failing because Entra now signs with a certificate our
    product does not yet trust (or, equally, our product rejects an expired one).
  - The good news: the replacement already exists, so we do not need to create
    one. We need to get it into our product and make sure it is the active one.
  - Because our product holds one certificate only, the swap is a short
    downtime step, and it is already an outage, so the window is "now" rather
    than a scheduled one. Still agree it with the client.

STEPS (who)
  1. (Us) Preserve evidence: failed sign-in entries, error text from our product
     (assertion signature / certificate expired), time stamps.
  2. (Us + Contoso administrator, screen share) Confirm: Enterprise apps >
     <app> > Single sign-on > SAML Certificates > Edit: which certificate is
     Active, which is Inactive, expiry dates and thumbprints. Confirm that our
     product's current certificate thumbprint matches the expired one.
  3. (Contoso administrator) Download the Inactive 2029 certificate in the format
     our setup guide specifies (Base64 .cer or federation metadata XML).
  4. (Contoso administrator or us, per our product's process) Upload it as the
     trusted signing certificate in our product's SAML settings.
  5. (Contoso administrator) Make certificate active (ellipsis on the new row).
     Do steps 4 and 5 back to back, because with one certificate in the product
     the two must change together.
  6. (Everyone) Prove: a test user signs in; the interactive sign-in log shows
     Success; the Authentication Details tab shows a successful sign-in.
  7. (Us) Remove the old, expired certificate from our product, if it still
     appears, and record the change.

CHECK BEFORE AND AFTER
  Before: the Active certificate's expiry date and thumbprint; that the 2029
  certificate really is the one shown as Inactive (not another application's).
  After: new Success entries; no error on the next day's first sign-in;
  notification email addresses are set for the next expiry (60/30/7-day emails,
  up to five addresses; verify them in the portal if they were set by script).

LONGER TERM
  - Add a calendar entry for well before 2029 (and the notification emails).
  - Ask our engineering team to read the per-tenant federation metadata URL
    regularly (Microsoft recommends at least every 24 hours), accept more than
    one signing certificate, and promote the new one when it is activated, so
    the next rollover needs no downtime and no human action (Chapter 9).
  - Do not rely on apps that skip expiry validation; that is accidental
    protection, not a design.

WHY THIS WORKS AS AN ANSWER
---
It uses Microsoft's documented behaviour for expired plus inactive certificates,
puts a name against every step, treats the one-certificate limit honestly as a
short step that must be paired with activation, and ends with a design fix.