TLS-Gate: RĂŒckmeldung „noch unrund“ und eine Grenze nach v3.0.0

Von: Branko / CrumbBot (Claude Opus 5.5, Repo OZM_Nullfeld_v1)
Stand: 30. September 2026
Typ: EXTERNAL_SOURCE (Inbox-Regel §3, keine automatische Geltung, kein Brain-Status)
Charakter: RĂŒckmeldung nach einem Lesedurchgang, dazu eine Richtungsaussage von Branko. Ein Thema.
Quelle: TLS-Gate-Mock-Pipeline main = 093ff43 (Tag v3.0.0 = 10c2db9), Repo tlsgate-monitor-demo main = 3249586.
VorgÀnger: 2026-09-29_TLS-GATE-DEMO-GEMOCKT-UND-AUSSENSICHT_BRANKO.md, 2026-09-29_TLS-GATE-WURZELSCHLUESSEL-UND-BRUECKE-ZUR-OZM-CA_BRANKO.md.

Legende: ✅ real/geprĂŒft · đŸ§Ș Test belegt es · 🛠 Vorschlag/Entwurf · ⬜ OPEN · ❓ UNKNOWN

Keine Secrets. Die Demo-Domain ist eine eigene Domain des Autors, sie steht hier wie zuvor als <domain>.

1. Worum es geht

Branko (O-Ton sinngemĂ€ĂŸ): Die ansiblekatze hat in kurzer Zeit sehr viel auf einmal verschraubt. UngefĂ€hr zwei Stunden hat es heute
gebraucht, um zu verstehen, was geht und was noch nicht. Dass die Doku dicht ist, hat das erst möglich gemacht.
Diese RĂŒckmeldung sammelt, was beim Lesen nicht zusammenpasst, und schlĂ€gt eine Grenze vor.

2. Befunde aus dem Lesedurchgang (✅ = im Repo nachgesehen, nichts geĂ€ndert)

# Befund Status Beleg
1 Das Vokabular fĂŒr source driftet: Der Vertrag nennt mock | fixture | live, der Export schreibt aber node_ca, der Monitor kennt zusĂ€tzlich node_ca und mixed ✅ docs/DESIGN_TENANTS.md Schritt 6 · tlsgate-monitor-demo/echt.json · sample.html Z. 557/574
2 Vertrag tlsgate.monitor steht weiter auf version: 1, obwohl sich das Vokabular erweitert hat ✅ beide Export-JSONs
3 clock: "lokale Uhr der Node" steht neben generated_on: "Mac". Die Aussage stimmt fĂŒr diesen Lauf nicht ✅ echt.json, kopie-fixture.json
4 sans im Export ohne die Hauptdomain (nur www.<domain>); im Mock (sample.json) steht die Domain mit in sans, das Zertifikat trĂ€gt laut Runbook beide ✅ Export-JSONs vs. sample.json · docs/LAUF_NODE_CA.md
5 evidence listet self_reported doppelt, ohne Bezug zum Ereignis. FĂŒr den Leser des Monitors wenig aussagekrĂ€ftig ✅ Export-JSONs
6 Zwei Kopien des Monitors laufen schon auseinander: Die Demo-Kopie kennt weder revocation noch issuer_kind ✅ diff resources/mock/sample.html tlsgate-monitor-demo/sample.html (Z. 671–675)
7 README der Demo nennt sample.html „gerenderte Ansicht zu sample.json“. TatsĂ€chlich ist sie der Leser (?data=) mit eingebetteten Beispielen ✅ tlsgate-monitor-demo/README.md
8 sample.json trĂ€gt soap_username/api_endpoint: als Mock in Ordnung, im Export verboten. Kein Hinweis, dass es keine Vorlage ist ✅ sample.json, DESIGN_TENANTS Schritt 6
9 Deploy widerspricht sich beim CLI-User: Das vhost-Beispiel sagt sudo -u <WEBUSER> 
 migrate, die README sagt, genau das lehnt der CLI-Guard ab (verlangt euid 0) ✅ deploy/apache-vhost.conf.example Z. 8 · deploy/README.md Z. 27

Was gut ist und bleiben soll: Außensicht (outside) und Selbstmeldung stehen in getrennten Spalten. Die Fixture zeigt issued
und gleichzeitig no_tls. Ausgestellt ≠ ausgeliefert wird damit sichtbar statt behauptet.

3. CLI im RZ ist eine andere Kiste

  • ✅ Lokal lĂ€uft TLS-Gate ĂŒber bin/serve.sh (php -S 127.0.0.1:8080) als User auf dem eigenen Rechner. Das Runbook zur Node-CA ist
    auf einem Mac gelaufen, nicht auf einer Node und nicht im RZ.
  • ✅ (laut Branko) Der FPM-Weg (Apache + PHP-FPM) scheint im RZ soweit zu laufen.
  • ⬜ Der CLI-Weg im RZ ist bisher nur vermutet, nicht gelaufen. Dort kommen zusammen: php-cli und FPM mit je eigener php.ini
    und eigenem User; Cron-Tick (order_tick.php) und Export schreiben, der Web-User muss lesen; TLSGATE_GUARD verlangt root, root legt
    Dateien an, die danach dem Web-User ĂŒbergeben werden mĂŒssen (Befund #9 zeigt, dass schon die Doku das uneinheitlich sagt).
  • Aus „lĂ€uft lokal mit serve.sh“ folgt nicht „lĂ€uft im RZ“. Aus „FPM lĂ€uft“ folgt nicht „Cron-CLI lĂ€uft“.

4. Richtung (Branko): Grenze nach v3.0.0

🛠 Vorschlag, nicht entschieden:

  • v3.0.0 ist die PHP-Referenz. Was danach kommt, wird nicht mehr in PHP verschraubt, sondern als Befund oder Vertrag festgehalten.
    Die Befunde aus §2 werden dort nachgezogen, wo sie den Vertrag betreffen (#1–#4), der Rest wird notiert.
  • Die alten v1-.sh-Skripte (im Tag v1.0.0 u. a. dashboard.sh, test_smoke.sh) funktionieren laut Branko sehr gut. EinschrĂ€nkung: Eine neue Order
    lĂ€sst sich nur ĂŒber die UI starten.
  • Rust-Ableitung aus dem Bash-Teil, nicht aus dem PHP-Teil: auf User-Ebene (kein root-Guard, kein Web-User-Wechsel), mit
    interner, eigener DB. Damit fĂ€llt die CLI/FPM-Rechte-Frage aus §3 fĂŒr den Rust-Teil weg, statt gelöst werden zu mĂŒssen.
    Muster wie bei missions-core: Bash-Baum bleibt Quelle, Rust wÀchst als Ableitung.
  • Warum jetzt der scheinbare „Overhead“: TLS-Gate soll spĂ€ter in dieser Form in Rust gegossen werden. Die Doku heute ist die Vorlage dafĂŒr.

5. Warum das fĂŒr Nullfeld zĂ€hlt

  • 🛠 Wenn der questions-server entsteht, sollen sich questions-core und missions-core dort anmelden. Das ist der Punkt, an dem
    TLS (bzw. eine eigene CA mit mTLS) im Rust-Kern ankommt.
  • ✅ Heute gilt das Gegenteil, bewusst: questions-core/Cargo.toml Z. 14–16 hĂ€lt fest, dass der Kern kein TLS hat
    („the door is the tunnel, not TLS“, Zugang nur ĂŒber wg0). Eine Anmeldung per Zertifikat wĂ€re also eine Änderung dieser Entscheidung,
    keine ErgĂ€nzung. ⬜
  • ✅ In TLS-Gate gibt es mit cert_whois (CertIdentity) schon die Frage „wohin gehört dieses Zertifikat“. Das ist die whoami-Kante aus
    dem Glossar, nur von der TLS-Seite her.

6. Was ausdrĂŒcklich nicht folgt

  • Aus „eigene CA geplant“ folgt nicht „Node-CA ist die OZM CA“. Die Node-CA ist eine Test-CA ohne OCSP und ohne SchlĂŒsseltrennung.
  • Aus „FPM lĂ€uft im RZ“ folgt nicht „TLS-Gate lĂ€uft im RZ“.
  • Aus „Rust-Ableitung geplant“ folgt nicht, dass es dafĂŒr Code gibt. Es gibt keinen.

7. Fragen an OZMAI (⬜)

  1. TrĂ€gt die Grenze „v3.0.0 = PHP-Referenz, danach Befunde statt Code“, oder braucht es vorher noch ein v3.0.1 fĂŒr die Vertragsdrift (#1–#4)?
  2. Soll source fĂŒr eine gemischte Kette (mixed) ein eigener Wert sein, oder wird nur die schwĂ€chste Quelle angezeigt (Frage aus dem VorgĂ€nger, §5)?
  3. Anmeldung von questions-core/missions-core am questions-server: Tunnel und Zertifikat (zwei getrennte PrĂŒfungen, Admission ≠ Verification),
    oder ersetzt eines das andere?