Dreizehn rote Pruefungen, eine Ursache: openssl steht nicht im PATH

DER BEFUND

Im naechtlichen Lauf standen dreizehn Pruefungen mit derselben Zeile
rot:

    [uncaughtException] Error: spawnSync openssl ENOENT

Kein Programmfehler. Die Pruefungen brauchen einen https-Vorbau (der
Sitzungskeks des Hauses ist `secure` und kommt ueber http nicht an),
und dafuer erzeugen sie ein Wegwerf-Zertifikat mit openssl.

GEMESSEN, NICHT VERMUTET

  openssl liegt hier:   C:\Program Files\Git\mingw64\bin\openssl.exe
                        C:\Program Files\Git\usr\bin\openssl.exe
  im System-PATH steht: C:\Program Files\Git\cmd   (nur git.exe)
  im Benutzer-PATH:     nichts mit Git

Wer aus Git Bash startet, erbt die mingw-Pfade und merkt nie etwas.
Die Aufgabenplanung startet `node.exe` DIREKT, ohne Shell -- und
bekommt sie nicht. Bei mir gruen, nachts rot, und der Grund steht
nicht im Code.

Das Schlimmste daran ist nicht der Ausfall: Dreizehn dauerhaft rote
Zeilen in einer Notiz, die Filipe morgens liest, gewoehnen einem das
Hinsehen ab -- und decken dabei die echten Befunde zu.

DIE REPARATUR

`server/helfer-openssl.mjs` sucht openssl erst im PATH (ohne `where`
oder `which` -- beides sind selbst Programme und koennen genauso
fehlen), danach an den Orten, an denen es auf einem Windows-Rechner
mit Git wirklich liegt.

Dazu `zertifikatBauen(schluessel, zertifikat, host)`. Die acht
Aufrufformen im Haus waren identisch bis auf die Variablennamen
(schl/zert, schluesselDatei/zertDatei, zKey/zCrt, sk/zt, key/crt) --
eine Stelle traegt alle neunundzwanzig. Zwei Tage zuvor war eine
davon um ein `-addext` aermer als die anderen; gemerkt hat es
niemand, weil der Browser den fehlenden Alternativnamen erst bei
einer Weiterleitung anmahnt. Eine Stelle kann nicht von sich selbst
abweichen.

KEIN EINTRAG IN DEN SYSTEM-PATH. `mingw64\bin` enthaelt rund hundert
Programme mit Unix-Namen (`find`, `sort`, `link`), die gleichnamige
Windows-Befehle verdecken. Das fuer eine Pruefung zu aendern haette
an ganz anderen Stellen Fehler verursacht, die niemand hierher
zurueckverfolgt.

GEGENPROBE IN BEIDE RICHTUNGEN, mit dem PATH des Nachtlaufs:

  vorher (direkter Aufruf):  ABSTURZ: spawnSync openssl ENOENT
  nachher (ueber den Helfer): Zertifikat gebaut, 1236 Bytes

Und eine echte Pruefung unter denselben Bedingungen:

  PATH ohne mingw64 -> pruef-chat-neu-stelle
  63 Pruefungen, 0 Fehler, 0 Abstuerze

Genau diese Datei stand im Nachtlauf mit ENOENT rot.

EINE WACHE DAGEGEN

pruef-struktur prueft ab jetzt, dass niemand openssl wieder direkt
ruft -- der naechste merkt es dort und nicht erst in einem
Nachtlauf, den niemand liest. Drei Gegenproben.

Beim ersten Anlauf schlug sie auf ihre EIGENEN Probetexte an: Sie
liest alle Serverdateien, und dazu gehoert sie selbst. Die Texte
werden jetzt zusammengesetzt. Derselbe Selbsttreffer ist mir heute
schon zweimal passiert.

DER DRITTE AUSGANG BLEIBT, WO ER HINGEHOERT

`helfer-kachel-echtfarbe.mjs` faengt den Fehler weiterhin ab und
meldet `moeglich: false` mit Grund, statt abzubrechen. Eine
Sicherung abzuschaffen, weil ihr Anlass gerade behoben ist, ist der
Anfang des naechsten stillen Fehlschlags.

NEBENBEI: pruef-community-sicht

Sie war rot mit "ZU VIEL: reaktion.html" -- mein eigener Rueckstand
vom 28.09. Die Reaction steht als Kachel im Community-Bereich; die
Liste war nicht nachgezogen. Jetzt 10 / 0.

Die Liste bleibt bewusst von Hand gepflegt: Sie ist eine ABSICHT,
keine Ableitung. Aus rechte.js gelesen verglichen sich zwei Kopien
derselben Quelle -- immer gruen, nie ein Beweis.

GEPRUEFT
  pruef-struktur         ALLES IN ORDNUNG (mit der neuen Wache)
  pruef-community-sicht  10 / 0
  pruef-chat-neu-stelle  63 / 0  (mit dem PATH des Nachtlaufs)
  pruef-notizen, -teamlage-karten, -werdegang: EXIT 0, keine Abstuerze
  mess-quer              EXIT 0
  29 Dateien: node --check auf allen, kein direkter Aufruf mehr

server/helfer-kachel-echtfarbe.mjs

@@ -37,6 +37,7 @@ import { DatabaseSync } from "node:sqlite";
 import { scryptSync, randomBytes } from "node:crypto";
 import { createServer } from "node:https";
 import { request as httpAnfrage } from "node:http";
+import { zertifikatBauen } from "./helfer-openssl.mjs";
 
 const HIER = dirname(fileURLToPath(import.meta.url));
 const CREW = "crew.dogfather-universe.com";
@@ -127,12 +128,21 @@ export async function pruefeEchteFarben({ port = 4369, breite = 1500 } = {}) {
     /* Chromium zwingt crew.… per eingebauter HSTS-Liste auf https --
        deshalb derselbe selbst unterschriebene Vorbau wie überall. */
     const zKey = join(ordner, "k.pem"), zCrt = join(ordner, "z.pem");
+    /* HIER BLEIBT DAS try/catch -- anders als an den 28 anderen
+       Stellen. Diese Datei hat einen dritten Ausgang: Sie sagt
+       „moeglich: false" samt Grund, statt den ganzen Lauf
+       abzubrechen. Ein fehlender https-Vorbau ist hier kein Befund
+       ueber die Farben, sondern „konnte nicht nachsehen".
+
+       Seit dem 29.09.2026 sucht `zertifikatBauen` openssl auch
+       ausserhalb des PATH -- der Fall sollte damit nicht mehr
+       eintreten. Der Ausgang bleibt trotzdem stehen: Eine Sicherung
+       abzuschaffen, weil ihr Anlass gerade behoben ist, ist der
+       Anfang des naechsten stillen Fehlschlags. */
     try {
-      execFileSync("openssl", ["req", "-x509", "-newkey", "rsa:2048", "-nodes",
-        "-keyout", zKey, "-out", zCrt, "-days", "2", "-subj", `/CN=${CREW}`,
-        "-addext", `subjectAltName=DNS:${CREW}`], { stdio: "ignore" });
-    } catch {
-      return { moeglich: false, grund: "openssl ist nicht da (fuer den https-Vorbau)" };
+      zertifikatBauen(zKey, zCrt, CREW);
+    } catch (f) {
+      return { moeglich: false, grund: `openssl: ${f.message.split("\n")[0]}` };
     }
 
     const HTTPS_PORT = port + 1;