B.W.A TLS-Gate // Architektur-Blaupause: vom SSL-Tool zum Mandanten-Core

Stand: 2026-09-24 · Status: Entwurf zur Abstimmung mit dem RZ
Anlass: Die erste echte Verlängerung mit Chain wurde sauber ausgestellt und deployed. Damit wird sichtbar,
was fehlt: Reseller mit eigenem Partnergate-Zugang, deren Domains wir verwalten. Dazu kommen Stammdaten wie
„bezahlt bis“ und später acme.sh für Let's Encrypt.

Leitgedanke: Wir bauen einen Core (Login, Mandanten, Stammdaten, Audit, Job-Queue). SSL/Partnergate
ist darin ein Modul unter mehreren. Der Core kann die alten PHP-, Ruby- und Python-Tools nach und nach
ablösen, aber einzeln und nie alle auf einmal.

Diese Datei ist ein Plan, kein Ist-Stand. Den Ist-Ablauf beschreibt PROZESS.md.

1. Befund: Mandanten über forReseller (Weg B) trägt

Geprüft wurde gegen die PDF-Doku und gegen die Live-WSDL
(https://www.domain-bestellsystem.de/soapstatus/wsdl/soap.wsdl, abgerufen am 2026-09-24). Wenn sich beide
widersprechen, gilt die WSDL (siehe den Fehler validationtyp/validationtype in README.md).

Konsequenz: Wir arbeiten mit unserem eigenen Partner-Zugang und setzen pro Anfrage forReseller
auf die Reseller-ID des eingeloggten Mandanten. Wir speichern keine fremden Partnergate-Passwörter.
Die Reseller behalten ihren eigenen Zugang zum Partnergate. Unser Tool braucht ihn nicht.

Achtung, heutiger Stand im Code: SslHandler.php ruft sslListExtended mit level => 'own' auf, und
forReseller ist überall fest ''. Reseller-Zertifikate sind im Inventar heute also gar nicht sichtbar.

Vor dem Umbau live zu prüfen (nur lesend, ohne Risiko)

1. sslListExtended mit level=all → enthält die Antwort Orders mit gefülltem Feld reseller?
2. sslInfo(orderNumber, forReseller=<ID>) für eine bekannte Reseller-Order → Returncode 1000?
3. Dieselbe Order mit falscher forReseller-ID → kommt 2004? (Belegt, dass die Mandantengrenze auch serverseitig durchgesetzt wird.)
4. Ist reseller in der Antwort dieselbe ID, die forReseller erwartet?

Werkzeug dafür: soap_cli.php probe. Es arbeitet nur lesend und ohne Rückfall auf die Mockdaten. Exit 0 heißt
returnCode 1000, Exit 1 heißt API-Fehler oder keine Verbindung.

php soap_cli.php probe list --level own               # Vergleichsbasis = heutiger Stand
php soap_cli.php probe list --level all               # 1. byReseller zeigt Reseller-IDs?
php soap_cli.php probe list --level reselleronly      #    (Wert bei SSL undokumentiert — testen)
php soap_cli.php probe info <order> --for-reseller <ID>      # 2. erwartet 1000, reseller == <ID> (4.)
php soap_cli.php probe info <order> --for-reseller gibtsnicht # 3. erwartet 2004
php soap_cli.php probe list --level all --expiring 10 # ersetzt JSON → CSV → awk $6

2. Der eigentliche Knackpunkt: die Stammdaten („bezahlt bis“)

Die ersten Bash-Tests liefen so: soap_cli.php → JSON → CSV → awk auf Spalte 6 → alle Zertifikate, die in
den nächsten 10 Tagen erneuert werden müssen. Das beantwortet aber nur „läuft ab?“, nicht
„soll verlängert werden?“. Ein Zertifikat kann technisch gültig sein und trotzdem wissentlich nicht
verlängert werden, weil der Kunde nicht mehr zahlt.

Nebenbei: Das Filtern auf „läuft ab“ kann die API selbst übernehmen. sslListExtended kennt den Filter
expiring=<Tage> (PDF S. 166), und SslHandler.php reicht ihn bereits durch (list_expiring). Der
awk-Schritt fällt damit weg.

Was die API zu „bezahlt“ hergibt

• domainInfo → paidUntilDate: laut PDF S. 50 nur, „sofern im System hinterlegt“, und nur für
  Domains „aus dem eigenen Bestand“, also Domains, die dort als Registrar geführt werden.
• billingData / billingDataExtra (PDF S. 211 ff.): Rechnungsposten pro Monat, nur für Reseller mit
  direktem Vertragsverhältnis. Daraus lässt sich die Abrechnung ablesen, aber kein „bezahlt bis“ pro Kunde.
• Für SSL-Orders gibt es kein Feld „bezahlt bis“. Kunden, deren Domain woanders registriert ist, liefert
  die API gar nichts dazu.

→ Die Wahrheit über „bezahlt bis“ liegt bei uns (Stammdaten), nicht beim Partnergate.

Regel: Stammdaten zuerst

1. Vorab importieren (Hintergrundjob) aus den bestehenden Kunden- und Abrechnungssystemen, dazu
   paidUntilDate aus domainInfo, wo vorhanden, mit Angabe der Quelle.
2. Wenn nichts importiert wurde, müssen die Stammdaten spätestens im Erneuerungsprozess erfasst
   und gespeichert werden. Die Verlängerung wartet, bis das geschehen ist.
3. Entscheidung pro Order:

„Nicht verlängert“ ist damit eine dokumentierte Entscheidung und kein Versehen. Das ist der Krümel.

3. Datenmodell (Entwurf)

tenants           id, name, typ (eigen|reseller), pg_reseller_id (→ forReseller), parent_id, aktiv
customers         id, tenant_id, name, kundennummer, vertrag_status
contracts         id, customer_id, domain, paid_until, source (import|domainInfo|manuell),
                  source_ref, updated_by, updated_at
users             id, tenant_id, email, pw_hash (argon2id), role, webauthn_*, totp_secret_enc,
                  locked, last_login
cert_inventory    id, tenant_id, customer_id, domain, source (partnergate|acme),
                  order_number, product_id, status, valid_to, last_seen
renewal_decisions id, cert_id, decision (renew|let_expire|blocked), reason, decided_by, decided_at
jobs              id, tenant_id, type, payload, state (queued|running|done|failed), result, attempts
audit_log         id, ts, user_id, tenant_id, action, target, result, ip   ← nur anhängen, kein UPDATE/DELETE

• Mandantentrennung zentral: Jede Abfrage läuft über eine Repository-Schicht, die tenant_id aus der
  Session erzwingt. Module schreiben kein eigenes WHERE tenant_id. Zusätzlich möglich: Postgres Row-Level-Security.
• cert_inventory ist ein gemeinsamer Bestand für Partnergate und acme.sh.
• state/state.json und state/actions.log bleiben als Vorstufe erhalten, bis die DB sie ablöst.
  Der Import erfolgt einmalig.

Startbasis: wptransformer (läuft produktiv auf wptransformer.org, Mandanten mit DB)

Maßgeblich ist das Repo ~/wptransformeer-OZMv0, denn es ist weiter als der Online-Stand (v1.0.2): Reset mit
SHA-256-gehashtem Token, Db.php für MySQL und Postgres, post_types. Nur online existieren zwei
Änderungen, die zurück ins Repo gehören:
- .htaccess sperrt zusätzlich *.log und *.ndjson. Im Repo fehlt das, dort wären die Logs öffentlich abrufbar.
- contact.php fängt es ab, wenn mail() auf dem Hoster deaktiviert ist.

4. Login: „so hart wie vorgeschrieben“

Solange nur Admins im Admin-VPN arbeiten, ist das Risiko gering. Sobald Reseller auf ihre Domains und
Kunden zugreifen, verlässt der Zugang das VPN. Ab dann gilt:

Netztrennung als zweite Schutzschicht: Admin- und Schreibfunktionen für alle Mandanten bleiben nur im
Admin-VPN. Das Reseller-Portal ist eine eigene, schmale Oberfläche, die nur den eigenen Mandanten sieht.

Wiederverwendung aus bestehenden Repos

5. Module

            ┌───────────────── Core ─────────────────┐
 Web (PHP) ─┤ Auth/MFA · Mandanten · Stammdaten ·     │
            │ Audit · Job-Queue · Secrets             │
            └───────┬───────────────┬─────────────────┘
                    │ jobs          │ jobs
          ┌─────────▼──────┐  ┌─────▼────────┐  ┌───────────┐
          │ ssl-partnergate│  │ acme (acme.sh)│  │ dns (spät.)│
          │ SslHandler     │  │ DNS-01        │  │ CNAME/TXT │
          └────────────────┘  └──────────────┘  └───────────┘

Gemeinsame Schnittstelle CertProvider: list · status · issue · renew · revoke.
Partnergate und acme.sh sind zwei Umsetzungen davon.

acme.sh
- Wird nie aus dem Web-Request gestartet. Das Web schreibt einen Job, ein Worker mit eigenem Systemuser
führt acme.sh aus. Das entspricht der bestehenden Linie „kein shell_exec“ (Cross-Check ist PHP-nativ).
- DNS-01 über den eigenen DNS. Der DNS-Baustein wird geteilt: Partnergate-DCV (CNAME) und ACME-DNS-01
(TXT) sind derselbe offene Schritt 6 aus PROZESS.md.
- Account-Keys und Zertifikate unter einem eigenen --home/--cert-home, nicht im Webroot.

Zielsysteme: Die alten FreeBSD-Hosts sind nur Ziele für das Deployment. Auf ihnen läuft kein Core-Code.

6. PHP jetzt, Rust später (OZM_Nullfeld_v1)

• Jetzt PHP, weil ext-soap ausgereift ist und SslHandler das gesammelte Wissen über die API enthält.
  In Rust gibt es keinen brauchbaren WSDL-Client. Das hieße, XML von Hand zu schreiben, und genau dort
  liegen die Doku-Fehler.
• Die Nahtstelle zu Rust ist die DB: Die Tabellen jobs, cert_inventory und audit_log bilden den
  Vertrag. Ein späterer Rust-Worker (axum/tokio, wie questions-core) arbeitet dieselbe Queue ab, und PHP
  bleibt als schlankes Frontend.
• Zuerst sollte der Teil mit den meisten Rechten migriert werden: Secrets, acme.sh-Ausführung, SOAP-Schreibaufrufe.
• Datenbank: In der Mockup-Phase SQLite, eine Datei in state/ und kein Server. Postgres (mit Rollenrechten
  und Row-Level-Security) kommt erst mit dem Rust-Core. Das Schema bleibt schlicht, damit der Umzug leicht fällt.
• Abgesichertes PHP-Setup: PHP ≥ 8.3 auf einem neuen Host (nicht auf den alten FreeBSDs), eigener
  php-fpm-Pool und User, disable_functions (exec, shell_exec, system, passthru, proc_open, popen) im Web-Pool,
  open_basedir, Secrets außerhalb des Webroots, Cookies mit Secure/HttpOnly/SameSite=Strict, CSP,
  ausschließlich Prepared Statements, sodium, Argon2id.

7. Meilensteine

Zwischen den Meilensteinen läuft das bestehende Tool unverändert weiter. Es wird nichts „big bang“ umgestellt.