TLS-Gate v3.13.0: Code-Stand im Audit, SSL-<n> = ID <n> bestätigt

Von: Branko → OZMAI, Crew
Stand: 11. Oktober 2026
Typ: EXTERNAL_SOURCE (Inbox-Regel §3, keine automatische Geltung, kein Brain-Status)
Charakter: NACHTRAG + Antwort auf 2026-10-10_ANTWORT-OZMAI_CRUMBFOREST-LOGIN-031200.md §2 und 2026-10-10_ANTWORT-OZMAI_USER-TEST-MFA-CREW402.md §3.
Ersetzt drei Aussagen:
(1) 2026-10-09_TLS-GATE-CRUMBFOREST-LOGIN-031200-STATEMENT_BRANKO.md §0: „Ob dafür ein eigener Tag gesetzt wird, ist offen“ → Tag v3.13.0 = 00bad35.
(2) 2026-10-10_TLS-GATE-USER-TEST-AKTIVIEREN-… §3 zu OZMAI §2: „Commit-Stand beim Image-Bau festhalten und im Audit mitschreiben … Nicht gebaut“ → gebaut, §1.
(3) Die offene Frage „SSL-4 = ID 4 der Produktliste?“ (zuletzt 2026-10-10_TLS-GATE-24-MONDE-… §6) → von Branko bestätigt, §2.
Quelle: Repo TLS-Gate-Mock-Pipeline, Tag v3.13.0 = 00bad35 (Inhalt 2e4a0d5; Vorgänger v3.12.0 = 5e064de, dazwischen 04c6095 … 7822f46).
Belege: lokal 35 von 35 Suiten grün, neu tests/test_build_stamp.sh (25). VM nach docker_vm/build.sh aus genau 00bad35: run 91 (+4), p3 48, p4 54, p5 31, p6 22, p7 50. ozm01, ozm02, ozm03 tragen commit=00bad35… dirty=0.

Legende: ✅ real/gebaut · 🧪 gebaut, getestet, nicht live · 🛠 spezifiziert · ⬜ OPEN · ❓ UNKNOWN

Keine Zugangsdaten, keine Kunden-Domains, keine Reseller-IDs, keine Ausgaben aus echten Läufen.

1. Code-Stand im Audit (Antwort auf OZMAI: VERSION_LABEL ⇏ EXACT_IMPLEMENTATION_STATE)

  • 🧪 Beim Image-Bau: docker_vm/build.sh gibt den Commit und dirty=0|1 ins Image. dirty=1 bedeutet: native_php, native_bash_cli oder docker_vm wichen beim Bau vom Commit ab. Die Instanz trägt den Stand als app/BUILD, instance.sh meldet ihn.
  • 🧪 Im Audit: Aktionen, die den Registrar berühren oder seine Antwort verarbeiten, tragen ctx.build: ssl.*, cli.inventory_sync, cli.order_tick, cli.cred_test, web.cred_test, cli.catalog_import_products. Das gilt auch für Läufe ohne Änderung, dry_run, rejected und denied. Andere Aktionen bleiben unverändert.
  • 🧪 Kurzform: <12 Hex> heißt aus dem Commit gebaut. <12 Hex>-dirty heißt mit Abweichung oder ohne Angabe gebaut. <12 Hex>-git steht für eine Arbeitskopie, deren Änderungen nicht geprüft wurden. Sonst steht dort unbekannt. Ein Bau ohne build.sh erzeugt also keinen erfundenen Stand.
  • 🧪 Der Seitenkopf zeigt nach der Anmeldung v3.13.0 @00bad35e323c. Im Klicktest ist damit sichtbar, welcher Stand antwortet (Lehre aus Browser-Cache und ozm01/ozm03).
  • ✅ Getaggt ist der Commit, der in der VM lief, nicht ein Stand davor. Die VM-Suite prüft das: app/BUILD gleich Host-Commit, dirty=0, Audit ssl.exportProducts mit ctx.build gleich Commit.
  • ⬜ Grenze: Ansible-Rolle und Betrieb sind nicht verdrahtet. Ohne BUILD steht dort …-git (Arbeitskopie) oder unbekannt. Der Image-Digest wird nicht erfasst (OZMAI: Kür). Damit bleibt welcher Code sollte laufen (Commit) von welches Artefakt lief (Digest) getrennt, der zweite Teil ist offen.

2. SSL-<n> = ID <n> (Branko, 11.10.)

  • ✅ Brankos Aussage: In der Order wird als Option nur die Ziffer übergeben, die SOAP-Details geben sie mit dem String-Präfix aus. SSL-4 im Bestand ist also die ID 4 der Produktliste.
  • 🧪 Ein gemeinsamer Vergleichsschlüssel (CatalogLoader::refKey) macht aus SSL-4, ssl-04 und 4 jeweils 4. Andere Formen bleiben, wie sie geliefert wurden (kein Raten). Gespeichert wird weiter der gelieferte Wert.
  • 🧪 Wirkung: Der Abgleich meldet SSL-4 nicht mehr als unbekannt, wenn der Katalog 4 aus dem Import führt. bestand.php zeigt den Katalognamen. stammdaten.php zeigt den Eintrag der Produktliste ohne Fragezeichen. Die Löschsperre im Katalog zählt genau 4 und SSL-4 (vorher LIKE '%-4').
  • ❓ Ob die Live-Instanz SSL-4/SSL-80 danach als bekannt führt, hängt davon ab, ob dort die Produktliste importiert ist (catalog_cli.php import-products). Das ist nicht bekannt.

3. Was NICHT belegt ist

  • ⬜ Der SOAP-Test auf v3.13.0. Er läuft erst in der isolierten Netzwerkumgebung im VPN, und die lag dem Entwickler nicht vor. Vorgesehen ist zuerst sync --dry-run. Im Audit steht dann ctx.build. Ergebnis nur als Brankos Aussage (ATTESTED_BY_BRANKO).
  • ❓ Wie die echte VM gebaut wird. Nur mit docker_vm/build.sh steht 00bad35e323c im Audit, sonst …-git oder unbekannt. Ein unbekannt im Live-Audit wäre ein Befund, kein Fehler des Stempels.
  • ⬜ Der Klick „aktivieren“ durch die Demo-User auf ozm03 steht aus. Die drei Buchungen für Crumbforest Login sind weiter offered.

4. Unverändert offen

  • ⬜ MFA code verpflichtend für Gruppen mit Root-, Managed- oder SSL-Freigaben, oder bleibt es Konvention (OZMAI: „sensitive effect requires independent binding“).
  • ⬜ Storno beim Registrar, sslReplace als „ersetzt“ abfragbar ❓, Order-Pool, Cron-JSON je Gruppe, Monitor für offered.
  • 🛠 Crew 402 bleibt Zielbild, nichts gebaut.

5. Einordnung als Prüffall (Branko, nicht OZMAI-Geltung)

Ein Tag benennt einen Commit, und ein Audit-Eintrag nennt jetzt den Commit, der ihn geschrieben hat. Beides zusammen beweist noch nicht, dass draußen derselbe Code lief. Es macht die Behauptung aber prüfbar: Steht im Live-Audit 00bad35e323c, lief v3.13.0. Steht dort etwas anderes, lief etwas anderes. Und unbekannt sagt genau das.