TLS-Gate v3.7.0: MFA-Standard für neue Gruppen per Env-Flag, Container neu gebaut

Von: Branko → OZMAI
Stand: 6. Oktober 2026
Typ: EXTERNAL_SOURCE (Inbox-Regel §3 — keine automatische Geltung, kein Brain-Status)
Charakter: STAND + NACHTRAG. Setzt 2026-10-06_TLS-GATE-V3-6-1-ORDER-ID-ROHLOG-ENTWURF-KATEGORIE-LAYER-NETBOX-ALS-SOT-NACHTRAG_BRANKO.md fort. Ersetzt keine Aussage früherer Dateien. Die Aussage dort („VM-Suiten für v3.6.1 nicht neu gestartet“) ist durch §1 überholt.
Quelle: Repo TLS-Gate-Mock-Pipeline (git.crumbforest.org). Tag v3.7.0 = Commit be42eff (Vorgänger v3.6.1 = b82e2a1).
Belege: tests/test_mfa_default.sh (8), mit vertauschtem Standard rot (7/1); VM-Suiten run 52, p3 48, p4 54, p5 31, p6 22 grün.

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

Keine Zugangsdaten, keine Kunden-Domains, keine Reseller-IDs.

1. Container neu gebaut (Docker aktualisiert)

  • ✅ Image tlsgate-vm mit dem aktualisierten Docker (Server 29.8.2) neu gebaut, Instanzen wieder angelegt, alle fünf VM-Suiten grün (Zahlen oben), zuerst mit v3.6.1-Code, dann mit v3.7.0.
  • 🧪 Grenze der Aussage „SSL läuft weiter“: Der Fake-Registrar bildet nur lesende Aufrufe nach (sslListExtended, sslInfo). sslReplace/sslCreate und damit der Rohlog-Pfad aus v3.6.1 sind in der VM nicht abgedeckt, nur durch den Host-Test test_writeinfo.sh. Ein echter Order lief nicht.
  • ⬜ Nach Rebuild fehlen weiter die Benutzer und /root/.provision/ssh; instance.sh stellt sie her (bekannte Falle).

2. Env-Flag TLSGATE_MFA_DEFAULT=qr|code

  • 🧪 Config::mfaDefault(): MFA-Modus neu angelegter Gruppen (group add, users.php). Ohne Angabe oder bei ungültigem Wert qr (vorher fest code). Bestehende Gruppen behalten groups.mfa_policy, Umstellen weiter per group mfa <slug> code|qr. Schema unverändert.
  • Annahme des Entwicklers, nicht bestätigt: Branko sagte „env flag für code oder qr, qr default“. Gelesen als Standard beim Anlegen, nicht als globaler Schalter über alle Gruppen. Ein globaler Schalter wäre ein anderer Eingriff (bestehende Gruppen mit ausdrücklich code wären dann nicht unterscheidbar).
  • 🧪 Bestehende Suiten, die den Code-Weg prüfen, setzen TLSGATE_MFA_DEFAULT=code; VM-Suiten stellen den MFA-Modus der Instanz selbst auf code.
  • ⬜ Nicht ins Pool-Template von instance.sh aufgenommen; in der VM gilt damit der Standard qr.

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

qr als Standard bedeutet: Das Passwort allein genügt zur Einrichtung, TOTP ist dann Sitzungsschlüssel, kein zweiter Faktor. Das ist im Sinn des Identitäts-Prüffalls eine schwächere Bindung als Voreinstellung; sie entsteht beim Anlegen, ohne dass jemand sie bewusst wählt. Für Root-/Managed-/SSL-Gruppen (bare, vm, ha, ssl) ist code vorgesehen. Wer das Flag auf qr lässt, muss den Wechsel nach dem Anlegen selbst vornehmen. ❓ Mit der Crew nicht besprochen; Entscheidung bei Branko bzw. OZMAI/Alex.

4. Offene Punkte

  • ❓ Soll qr als Standard auch für Root-/Managed-Gruppen gelten, oder braucht jede Produktart ihren eigenen Standard (Tabelle „Produkttypen“ im Entwurf nennt code für bare/vm/ha/ssl)?
  • ⬜ Order-ID-Frage aus v3.6.1 bleibt offen, bis ein echter sslReplace das Rohlog füllt.
  • ⬜ Domain-/Kategorie-Schema wartet auf die Crew (Fragen 7–9 im Entwurf).