diff --git a/docs/FIFA17_FUT_SQUAD_UPDATE_TLS.md b/docs/FIFA17_FUT_SQUAD_UPDATE_TLS.md
index 26d7ad4..e6ec4b7 100644
--- a/docs/FIFA17_FUT_SQUAD_UPDATE_TLS.md
+++ b/docs/FIFA17_FUT_SQUAD_UPDATE_TLS.md
@@ -1,7 +1,10 @@
 # FIFA 17 "FUT Squad Update" download failure — root cause
 
-**Status:** root-caused, not yet fixed. Blocks any FIFA session pointed at a stack whose
-roster server presents the current self-signed certificate.
+**Status:** FIXED in the cert generators (commit `fbc0da2`) — the SAN now carries the
+advertised IP. Verified without the client (a verifying TLS client rejects the old
+DNS-only cert by IP and accepts the new one; the entrypoint reconcile is idempotent).
+Live confirmation needs the production container rebuilt with `OPENFUT_ADVERTISE` set,
+which is operator-gated. See "Fix options (applied)" below.
 
 **Symptom (client):** entering the FUT hub shows
 
@@ -96,18 +99,23 @@ forces the fetch — but that has not been measured. The known-good hook log use
 control (Aug 12 19:13) **predates the Aug 13 certificate regeneration**, so it is not
 evidence about the current certificate.
 
-## Fix options (none applied)
+## Fix options — option 1 applied (`fbc0da2`)
 
-1. **Reissue the certificate with an `iPAddress` SAN** for the advertised address. Smallest
-   change, addresses the concrete mismatch, and benefits the redirector too. Note
-   `openfut-tls` exists precisely so the redirector and roster hosts cannot configure TLS
-   separately — the 2026-08-11 mismatch it was written for is the same class of bug.
-2. **Serve the roster over plain HTTP** for an isolated stack, by pointing
-   `ROSTERUPDATE_URL`/`ROSTER_URL` at a staging-owned HTTP server. Sidesteps TLS entirely;
-   only acceptable off production.
-3. **Find the real validation site** on the roster path and extend the patch set. Most
-   faithful, most work, and the only option that restores the original assumption.
+1. **Reissue the certificate with an `iPAddress` SAN** — **APPLIED.** The three cert
+   generators now put the advertised IP in the SAN: the docker entrypoint reconciles it at
+   startup from `OPENFUT_ADVERTISE` (runtime value, unknown at build time; reissued only
+   when missing, so restarts don't churn the fingerprint), the Dockerfile keeps `openssl`
+   in the runtime image and bakes a loopback-IP baseline, and `openfut-fut.sh` defaults the
+   SAN IP to the host's primary LAN IP. Smallest change, benefits the redirector too. Note
+   `openfut-tls` only *loads* the cert — it does not generate it — so the generation fix
+   lives in these three scripts regardless of whether the roster is served by Python or the
+   Rust `openfut-roster-host`.
+2. **Serve the roster over plain HTTP** — not taken. Sidesteps TLS entirely but only
+   acceptable off production, and option 1 fixes it properly everywhere.
+3. **Find the real validation site** on the roster path and extend the patch set — not
+   needed once the SAN matches; kept on record as the most-faithful alternative.
 
-Option 1 is the recommended starting point because it is testable without the client:
-a probe that validates hostname/IP against the presented certificate will fail before the
-fix and pass after.
+Option 1 was chosen because it is testable without the client: a verifying TLS client
+checking the cert by IP fails on the old cert and passes on the new one. That test now
+passes (`scripts`-style probe run at fix time); the remaining step is the operator
+rebuilding the production container so the reissued cert is actually served.