B.W.A TLS-Gate // Prozess-Blaupause

Zweck: Diese Datei beschreibt die Schritt-Reihenfolge fĂŒr eine SSL-VerlĂ€ngerung ĂŒber die aktuelle
CLI-Pipeline (dashboard.sh) — als Blaupause fĂŒr den geplanten Ziel-Zustand: ein tĂ€glicher Cron-Job, der
die Liste prĂŒft, benötigte Aktionen anstĂ¶ĂŸt (sofern gewollt) und Cert-/DNS-Daten aktualisiert.

Wichtig: Das hier ist der Ist-Stand (interaktiv/manuell ausgefĂŒhrt), nicht die Automatisierung selbst.
Abschnitt 4 listet explizit, was fĂŒr den Cron-Betrieb noch fehlt.

1. Schritt-Reihenfolge pro Order

# Schritt Kommando Wann auslösen Ergebnis / wohin
1 Inventur dashboard.sh / stats tĂ€glich, read-only Übersicht + Restlaufzeit-Farbcode (🔮<0d đŸŸ â‰€30d đŸŸĄâ‰€90d 🟱>90d)
2 Kandidaten bestimmen Liste nach Restlaufzeit filtern Restlaufzeit ≀ Schwellwert (z.B. 30d) und Status aktiv (ssl_ok o.Ă€.) Liste von orderNumbers zur VerlĂ€ngerung
3 CSR/Key erzeugen nur Web-UI (index.php → CSR & Key Generator) pro Kandidat, falls kein aktueller CSR/Key lokal vorhanden .csr/.key — Key verlĂ€sst nie den Server, muss lokal abgelegt werden (SSL/<domain>/<domain>.{csr,key})
4 VerlĂ€ngerung anstoßen dashboard.sh renew <orderNr> <csrFile> DNS [onBehalf] nach Schritt 3 Neue Order (eigene orderNumber, siehe Lektion unten), Status zunĂ€chst laufend
5 Validierungsdaten abrufen dashboard.sh details <neueOrderNr> (ggf. mehrfach pollen) direkt nach Schritt 4, bis validationDNS gefĂŒllt ist CNAME-Record (Format: _<MD5(CSR)>.<FQDN> CNAME <SHA256(CSR)>.<CA-hash>.comodoca.com.)
6 CNAME im eigenen DNS setzen außerhalb dieses Tools — bestehender DB/Puppet-Weg nach Schritt 5 DNS-Record live
7 Ausstellung abwarten dashboard.sh details <orderNr> (ggf. mehrfach pollen), comodostatus prĂŒfen nach Schritt 6, bis CA validiert hat status/comodostatus.certificateStatus Ă€ndert sich, certificate wird gefĂŒllt
8 Deploy dashboard.sh deploy <orderNr> sobald Zertifikat vorliegt schreibt .cert+.chain.pem, prĂŒft Match+Chain automatisch, aktualisiert state/state.json
9 Live-Abgleich (Gegenprobe) dashboard.sh openssl cross-check <orderNr> nach Deploy SOAP-Sollzustand vs. tatsÀchlich ausgeliefertes Zertifikat

NebenlĂ€ufig, nicht order-gebunden: authcode <domain> / owner <domain> — bei Bedarf, nicht Teil der
Renewal-Kette.

2. Lektionen aus dem ersten echten Testlauf (2026-09-10)

Diese Punkte MÜSSEN in jede Automatisierung einfließen, bevor sie auf den gesamten Domain-Bestand losgelassen wird:

  • Eine Domain kann mehrere Orders gleichzeitig haben (gesehen: ssl_ok + ssl_false + neue Reissue-Order).
    Schritt 2 darf niemals nur nach Domain gruppieren — immer die konkrete orderNumber tracken.
  • renew (sslReplace) erzeugt live eine eigene neue orderNumber fĂŒr den Reissue (nicht dieselbe wie
    die Ausgangsorder). Schritt 4 muss die neue orderNumber aus der Antwort ĂŒbernehmen, nicht mit der
    alten weiterarbeiten.
  • Nicht jede Domain, die im Domain-Bestellsystem gefĂŒhrt wird, wird auch tatsĂ€chlich von dort mit TLS
    versorgt.     Beispiel aschestein.de: lĂ€uft ĂŒber Webflow (CNAME → cdn.webflow.com), eigenes
    Google-Trust-Services-Zertifikat, komplett unabhÀngig vom Sectigo-Auftrag. Vor jedem automatisierten
    Deploy MUSS Schritt 9 (Cross-Check) zuerst laufen     — sonst ĂŒberschreibt ein Cron-Job im schlimmsten Fall
    sinnlos eine .cert-Datei, die dort gar nicht in Benutzung ist, oder ein Cron-Alarm feuert grundlos, weil
    das SOAP-Zertifikat "bald ablĂ€uft", obwohl live ein ganz anderes (lĂ€nger gĂŒltiges) Zertifikat bedient wird.
  • status-Werte (ssl_ok/ssl_off/ssl_false/ssl_revoke/...) sind nirgends dokumentiert. Eine
    Automatisierung darf nicht blind auf einen erwarteten Status warten — comodostatus.certificateStatus
    zusĂ€tzlich prĂŒfen und bei unbekanntem/negativem Status abbrechen statt endlos zu pollen.

3. Guardrails fĂŒr den spĂ€teren Cron-Betrieb

  • Dry-Run zuerst: Cron-Job sollte anfangs nur Kandidaten auflisten (Schritt 1+2), keine Schreibaktionen
    auslösen — Ergebnis manuell gegenlesen, bevor Schritt 4+ automatisch lĂ€uft.
  • Allow-/Skip-Liste je Domain: explizit pflegbare Liste, welche Domains die Automatisierung anfassen darf
    — verhindert genau das aschestein.de-Szenario oben.
  • Cross-Check vor Deploy, nicht nur danach: wenn das aktuell live ausgelieferte Zertifikat von einer
    anderen CA/mit anderer Restlaufzeit kommt als erwartet, Domain ĂŒberspringen + melden statt zu deployen.
  • Kein Fire-and-Forget bei DNS: Schritt 6 bleibt vorerst manuell (DB/Puppet-Weg) — ein Cron-Job darf hier
    höchstens den CNAME-Wert bereitstellen/melden, nicht selbst ins bestehende DNS-System schreiben, bis dafĂŒr
    eine eigene, geprĂŒfte Anbindung existiert.

4. Was fĂŒr "voll automatisiert per Cron" noch fehlt

  • CSR/Key-Erzeugung ist CLI-seitig nicht erreichbar — genCsr() existiert nur als Web-Formular-Action in
    index.php, kein soap_cli.php/dashboard.sh-Äquivalent. FĂŒr Cron-Betrieb nötig.
  • Kein Poll-/Wait-Mechanismus — Schritt 5 und 7 sind aktuell "manuell mehrfach details aufrufen". Ein
    Cron-Job brÀuchte einen Zustandsautomaten (z.B. state.json-Feld pending_since + nÀchster Cron-Lauf
    prĂŒft weiter, statt in einem Lauf zu blockieren).
  • Kein automatischer DNS-Rollout (siehe Guardrails oben) — Anbindung an das bestehende DB/Puppet-System
    bzw. spĂ€ter Ansible/NetBox ist ein eigenes Vorhaben, hier nur als LĂŒcke vermerkt.
  • Keine Benachrichtigung/Alerting bei FehlschlĂ€gen (ssl_revoke, Chain-Mismatch, Cross-Check-Drift) —
    aktuell landet das nur in state/actions.log, niemand wird aktiv informiert.