OpenFUT/docs/FIFA17_FUT_SQUAD_UPDATE_TLS.md

FIFA 17 "FUT Squad Update" download failure — root cause

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

An error occurred downloading the FUT Squad Update. Please try again.

Recovered from the live client's memory with scripts/client-error-string.py, not from a log. Nothing server-side reports an error: every UTAS route answers 200 and the Blaze session stays healthy, answering PINGs while the client sits on the dialog.

What it is

"Squad Update" here is the roster update, not the player's lineup. The Blaze responder advertises it as the FUT loading gate (blaze_responder_v3b.py):

ROSTER_HOST = "%s:8081" % _ADVERTISE
("ROSTERUPDATE_URL", "https://%s/fifa17/fut/rosterupdate.xml" % ROSTER_HOST)
("ROSTER_URL",       "https://%s/fifa17/roster/" % ROSTER_HOST)

The client fetches that URL over TLS, by IP, from roster_server.py.

Root cause

The client completes TCP, sends a ClientHello, receives the certificate, and then aborts the handshake itself. Captured and decoded from the wire:

CLIENT: ClientHello   client_version = TLS1.2
        offers 8 suites: RSA_AES_256_GCM_SHA384, RSA_AES_128_GCM_SHA256,
        RSA_AES_256_CBC_SHA256, RSA_AES_128_CBC_SHA256, RSA_AES_256_CBC_SHA,
        RSA_AES_128_CBC_SHA, RSA_RC4_128_SHA, RSA_RC4_128_MD5
SERVER: ServerHello TLS1.2 -> Certificate (909 B) -> ServerHelloDone
CLIENT: Alert  level=fatal  desc=certificate_unknown

Protocol and cipher selection are compatible — TLS1.2 with an RSA suite is offered and chosen. The client rejects the certificate:

subject/issuer = CN = winter15.gosredirector.ea.com   (self-signed, CA:TRUE)
SAN            = DNS:winter15.gosredirector.ea.com, DNS:*.gosredirector.ea.com, DNS:*.ea.com
notBefore      = Aug 13 01:12:30 2026
sha256         = FF:66:69:48:E2:02:AB:F4:A4:40:78:B1:8C:E1:F9:65:96:32:BB:FF:1F:3D:CC:BC:07:54:02:11:8F:4D:12:3F

Two facts matter:

1. The SAN carries DNS names only, no iPAddress entry, while the advertised URL is an IP literal (https://10.10.0.120:8081/...). A DNS-only SAN cannot match an IP dial.
2. The certificate was regenerated on Aug 13. roster_server.py loads the same redir_cert.pem/redir_key.pem as the Blaze redirector, so the redirector rejects identically — visible as REDIR REJECTED ... TLS/SSL connection has been closed (EOF) in the Blaze log. That is tolerated only because the client then reaches Blaze main over plain TCP; the roster fetch has no such fallback, so it is where the failure surfaces.

roster_server.py still carries the comment "ProtoSSL cert-verify is patched (autopatch), so our self-signed cert is accepted." That assumption no longer holds for this path. autopatch demonstrably patched both gates in the failing process — the log shows pid 56298: PATCHED cert gates and the live bytes read back as the patched patterns (909090909090 at 0x146132548, 31c0c3 at 0x1461361b0) — and the client still sent certificate_unknown. So those two gates do not govern this validation; either another check exists on the roster path, or it validates before reaching them.

Ruled out, with evidence

Hypothesis	Evidence against
Missing/mistyped UTAS field	0 structural differences across 14 hub routes vs production (scripts/hub-diff-prod-staging.py)
Player squad shape	matches production field-for-field, including squadType, custom, chemistry, manager
Squad save	PUT/GET round-trips exactly, every field and slot
Cert gates unpatched	autopatch log + live byte read both confirm patched
Roster server broken	serves 200, application/xml over TLS1.2 AES256-GCM-SHA384
Advertised host wrong	production and staging Blaze envs are identical for OPENFUT_ADVERTISE, POW_*; the scripts are byte-identical
TLS version mismatch	client offers TLS1.2 and the server selects it
Blaze session	healthy, PING/PING_REPLY throughout

Probing gotcha

A default modern Python TLS context gets SSLV3_ALERT_HANDSHAKE_FAILURE against this server and looks like a server fault. It is not — the server requires legacy-compatible cipher selection. Probe with ALL:@SECLEVEL=0, and note it rejects TLS1.0/1.1 outright (TLSV1_ALERT_PROTOCOL_VERSION), accepting only TLS1.2.

Why production appears unaffected

Unresolved, and worth stating plainly rather than guessing. Production advertises the same URL, backed by the same server and certificate, so the same rejection should occur. The operator reports production is clean. The likely explanation is that a production client does not re-fetch the roster (already satisfied), while a session against a different Blaze forces the fetch — but that has not been measured. The known-good hook log used as a control (Aug 12 19:13) predates the Aug 13 certificate regeneration, so it is not evidence about the current certificate.

Fix options — option 1 applied (fbc0da2)

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 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.