Merge branch 'workshop-angaben-tls-windows' into 'main'

Workshop-Angaben, TLS-Fixes, Windows-Tauglichkeit und einheitliche Stack-Steuerung

See merge request hkoeck/htl-reverse-proxy-tls-lab!1

.env.example

@@ -1 +0,0 @@
-HTTP_PORT=8080

Makefile

@@ -1,29 +0,0 @@
-.PHONY: bootstrap up down logs redeploy proxy-reload reset reset-hard reset-origin
-
-bootstrap:
-	./scripts/bootstrap.sh
-
-up:
-	./scripts/compose.sh up -d --build
-
-redeploy:
-	./scripts/compose.sh up -d --build --remove-orphans
-	./scripts/compose.sh restart reverse-proxy
-
-proxy-reload:
-	./scripts/compose.sh restart reverse-proxy
-
-down:
-	./scripts/compose.sh down
-
-logs:
-	./scripts/compose.sh logs -f
-
-reset:
-	./scripts/reset-lab.sh
-
-reset-hard:
-	./scripts/reset-lab.sh --hard
-
-reset-origin:
-	./scripts/reset-lab.sh --hard-origin

README.md

@@ -47,11 +47,11 @@ winget install --id OpenSSL.OpenSSL -e
 winget install --id WiresharkFoundation.Wireshark -e
 ```
 
-Nach der Installation von Docker Desktop aktiviere die WSL-Integration in den Einstellungen.
+Nach der Installation von Docker Desktop die WSL-Integration in den Einstellungen aktivieren.
 
 ### Linux / macOS
 
-Docker Engine oder Docker Desktop installieren (falls `make` fehlt auf macOS: `xcode-select --install`).
+Docker Engine oder Docker Desktop installieren.
 
 Optional fuer TLS-Challenges:
 
@@ -82,7 +82,13 @@ Falls PowerShell das Script blockiert:
 Set-ExecutionPolicy -Scope Process Bypass
 ```
 
-Alternativ im WSL-Terminal:
+Wenn mehrere WSL-Distros installiert sind:
+
+```powershell
+./scripts/workshop.ps1 -Action bootstrap -Distro Ubuntu-24.04
+```
+
+Alternativ direkt im WSL-Terminal:
 
 ```bash
 ./scripts/bootstrap.sh
@@ -97,52 +103,35 @@ Alternativ im WSL-Terminal:
 Das Skript:
 
 - prueft Docker + Compose
-- erstellt `.env` aus `.env.example` (falls nicht vorhanden)
 - startet den Stack
 
-Hinweis zu Skriptnamen:
+Der PowerShell-Wrapper ruft intern `./scripts/lab.sh` in WSL auf - dieselbe Steuer-Oberflaeche wie unter Linux/WSL.
-
-- `scripts/bootstrap.sh` ist der empfohlene Einstieg
-- intern nutzt es `scripts/bootstrap-unix.sh`
-- `scripts/bootstrap-wsl.sh` existiert nur noch als Kompatibilitaets-Wrapper
 
 ## Neu deployen / resetten
 
-### Windows
+Alle Aktionen laufen ueber `./scripts/lab.sh <aktion>` (in WSL/Linux). Windows-PowerShell-Nutzer nehmen `./scripts/workshop.ps1 -Action <aktion>` - dahinter steckt dasselbe Skript.
-
-Weitere Aktionen in PowerShell:
-
-```powershell
-./scripts/workshop.ps1 -Action redeploy
-./scripts/workshop.ps1 -Action proxy-reload
-./scripts/workshop.ps1 -Action reset
-./scripts/workshop.ps1 -Action reset-hard
-./scripts/workshop.ps1 -Action reset-origin
-```
-
-Wenn mehrere Distros installiert sind:
-
-```powershell
-./scripts/workshop.ps1 -Action bootstrap -Distro Ubuntu-24.04
-```
-
-### Linux / macOS
 
 ```bash
-make redeploy
+./scripts/lab.sh up
-make proxy-reload
+./scripts/lab.sh redeploy
-make reset
+./scripts/lab.sh proxy-reload
-make reset-hard
+./scripts/lab.sh down
-make reset-origin
+./scripts/lab.sh logs
+./scripts/lab.sh reset
+./scripts/lab.sh reset-hard
+./scripts/lab.sh reset-origin
 ```
 
+- `up`: build + start (entspricht dem, was `bootstrap` am Ende macht)
 - `redeploy`: build + restart aller Services
 - `proxy-reload`: nur Reverse Proxy restart
+- `down`: Stack stoppen (Container entfernen, Volumes bleiben)
+- `logs`: Logs aller Services folgen (`Strg+C` zum Beenden)
 - `reset`: Container/Netzwerk/Volumes aufraeumen
 - `reset-hard`: wie `reset`, plus lokale Git-Aenderungen verwerfen (falls Git-Repo)
 - `reset-origin`: wie `reset-hard`, aber bevorzugt Ruecksetzen auf `origin/main`
 
-Hinweis: `make redeploy` startet zusaetzlich den Reverse Proxy neu, damit Nginx-Config-Aenderungen sicher aktiv sind.
+Hinweis: `redeploy` startet zusaetzlich den Reverse Proxy neu, damit Nginx-Config-Aenderungen sicher aktiv sind.
 
 ## Kurz testen
 
@@ -151,6 +140,8 @@ curl http://localhost:8080/service/a
 curl http://localhost:8080/service/b
 ```
 
+> **Windows:** Diese und alle weiteren Test-Kommandos (`curl`, `openssl`, `grep`, Schleifen) im **WSL-Terminal (bash)** ausfuehren, nicht in PowerShell. In PowerShell ist `curl` ein Alias fuer `Invoke-WebRequest` und versteht die genutzten Flags (`-I`, `-k`, `--cacert`) nicht. PowerShell nur fuer den Stack-Wrapper `scripts/workshop.ps1`.
+
 ## Fokus im Workshop
 
 Die Basis ist bewusst nur HTTP. HTTPS ist Teil der Aufgaben:

backends/a/index.html

@@ -64,6 +64,7 @@
     </style>
   </head>
   <body>
+    <!-- INSTANCE=A -->
     <main>
       <span class="tag">Backend A</span>
       <h1>Reverse Proxy Target A</h1>

backends/a2/index.html

@@ -39,6 +39,7 @@
     </style>
   </head>
   <body>
+    <!-- INSTANCE=A2 -->
     <main>
       <h1>Reverse Proxy Target A2</h1>
       <p>Use this page to validate load balancing between backend-a and backend-a2.</p>

challenges/README.md

@@ -8,13 +8,29 @@ Diese Aufgaben sind bewusst auf **manuelle Proxy-Konfiguration** ausgelegt.
 - Done-Check Command live ausfuehren
 - 2-3 Saetze erklaeren: was geaendert, warum, welche Wirkung
 
+## Wo laufen die Kommandos? (besonders Windows)
+
+Die meisten Teilnehmer arbeiten unter **Windows mit Docker Desktop + WSL**. Wichtig:
+
+- **Stack steuern** (`./scripts/lab.sh ...` in WSL oder der PowerShell-Wrapper `scripts/workshop.ps1`): geht aus PowerShell **oder** aus dem WSL-Terminal.
+- **Alle Challenge-Kommandos** (`curl`, `openssl`, `grep`, `wget`, `for`-Schleifen, `./scripts/compose.sh ...`): laufen im **WSL-Terminal (bash)**, nicht in PowerShell.
+- **Warnung:** In PowerShell ist `curl` ein Alias fuer `Invoke-WebRequest` und versteht die hier genutzten Flags (`-I`, `-k`, `--cacert`) **nicht**. Immer im WSL-Terminal testen.
+- Das Repo liegt im WSL-Dateisystem oder unter `/mnt/c/...`; arbeite am besten aus dem WSL-Terminal im Projektordner.
+
 ## Arbeitsmodus
 
 1. Dateien anpassen (`proxy/nginx.conf`, `docker-compose.yml`).
-2. Deployen mit `make redeploy` oder `make proxy-reload`.
+2. Deployen: nach reinen `nginx.conf`-Aenderungen reicht `./scripts/lab.sh proxy-reload`; nach Aenderungen an `docker-compose.yml` (z. B. neue Ports oder Services) immer `./scripts/lab.sh redeploy`, da der Container neu erstellt werden muss.
 3. Testen mit `curl` / `openssl` / Wireshark.
 4. Bei Problemen: `./scripts/compose.sh logs reverse-proxy`.
 
+## Arbeitsweise (wichtig)
+
+- Es wird **additiv in einer einzigen `proxy/nginx.conf`** gearbeitet: jede Challenge erweitert den Stand der vorherigen. Loesungen nicht wieder loeschen - die TLS-Challenges (10-12) bauen direkt aufeinander auf.
+- **Ausnahme Challenge 9** (Debugging): Diese ueberschreibt die `nginx.conf` bewusst. Vorher sichern (`cp proxy/nginx.conf proxy/nginx.conf.bak`), danach wiederherstellen.
+- Jede Angabe nennt einen **Ausgangszustand** (worauf baue ich auf) und einen **Zielzustand / Akzeptanz** (woran erkenne ich "fertig"). Der Done-Check ist die pruefbare Form des Zielzustands.
+- Komplett zuruecksetzen geht jederzeit mit `./scripts/lab.sh reset` (Container/Volumes) bzw. `./scripts/lab.sh reset-hard` (zusaetzlich lokale Datei-Aenderungen verwerfen).
+
 ---
 
 ## Easy
@@ -24,45 +40,59 @@ Diese Aufgaben sind bewusst auf **manuelle Proxy-Konfiguration** ausgelegt.
 **Ziel**
 - Verstehen, wie Nginx Requests per Pfad an unterschiedliche Upstreams schickt.
 
-**Muss**
+**Datei**
+- `proxy/nginx.conf` (nur lesen)
+
+**Schritte (Muss)**
 - Vor dem Test in `proxy/nginx.conf` nachsehen, welche `location` auf welchen `upstream` zeigt.
 - Dann erst Requests ausfuehren.
 - In eigenen Worten erklaeren, warum die Antworten unterschiedlich sind.
 
-**Warum wichtig**
+**Zielzustand / Akzeptanz**
-- Das ist die Kernkompetenz bei Reverse Proxys: Request-Fluss lesen und korrekt begruenden.
+- Du kannst fuer `/service/a` und `/service/b` jeweils Location -> Upstream -> Backend benennen und begruenden, warum die Antworten unterschiedlich sind.
 
 **Done-Check**
 ```bash
-curl http://localhost:8080/service/a
+curl http://localhost:8080/service/a   # -> "Reverse Proxy Target A"
-curl http://localhost:8080/service/b
+curl http://localhost:8080/service/b   # -> "Reverse Proxy Target B"
 ```
 
+**Warum wichtig**
+- Das ist die Kernkompetenz bei Reverse Proxys: Request-Fluss lesen und korrekt begruenden.
+
 ### 2) Drittes Backend manuell hinzufuegen
 
 **Ziel**
 - Setup sicher erweitern, ohne bestehende Routen kaputt zu machen.
 
+**Ausgangszustand**
+- Stack laeuft, `/service/a` und `/service/b` antworten.
+- `backends/c/index.html` liegt bereits im Repo (Starterseite).
+
 **Dateien**
 - `docker-compose.yml`
 - `proxy/nginx.conf`
 - `backends/c/index.html` (vorhanden, darf angepasst werden)
 
-**Muss**
+**Schritte (Muss)**
 - Service `backend-c` in Compose einbauen.
 - Upstream + Route `/service/c` in Nginx anlegen.
-- A/B muessen weiterhin funktionieren.
+- Deployen mit `./scripts/lab.sh redeploy` (Compose-Aenderung -> Container-Neustart noetig).
 
-**Warum wichtig**
+**Zielzustand / Akzeptanz**
-- In realen Umgebungen kommen neue Services laufend dazu. Saubere Erweiterung ohne Regression ist entscheidend.
+- `/service/c` liefert Backend C.
+- `/service/a` und `/service/b` funktionieren unveraendert weiter (keine Regression).
 
 **Done-Check**
 ```bash
-curl http://localhost:8080/service/c
+curl http://localhost:8080/service/c   # -> enthaelt "Reverse Proxy Target C"
-curl http://localhost:8080/service/a
+curl http://localhost:8080/service/a   # -> weiterhin "Reverse Proxy Target A"
-curl http://localhost:8080/service/b
+curl http://localhost:8080/service/b   # -> weiterhin "Reverse Proxy Target B"
 ```
 
+**Warum wichtig**
+- In realen Umgebungen kommen neue Services laufend dazu. Saubere Erweiterung ohne Regression ist entscheidend.
+
 ### 3) Eigene Route mit Rewrite oder Alias-Route
 
 **Ziel**
@@ -71,18 +101,22 @@ curl http://localhost:8080/service/b
 **Datei**
 - `proxy/nginx.conf`
 
-**Muss**
+**Schritte (Muss)**
 - Route `/demo/a` anbieten, die auf Backend A fuehrt.
 - Entweder per rewrite oder per eigener proxy-Route loesen.
+- Deployen mit `./scripts/lab.sh proxy-reload`.
 
-**Warum wichtig**
+**Zielzustand / Akzeptanz**
-- Der Proxy entkoppelt externe API-Pfade von internen Service-Pfaden und ermoeglicht saubere Migrationen.
+- `/demo/a` liefert dieselbe Antwort wie `/service/a` (Backend A), obwohl der externe Pfad ein anderer ist.
 
 **Done-Check**
 ```bash
-curl http://localhost:8080/demo/a
+curl http://localhost:8080/demo/a   # -> "Reverse Proxy Target A"
 ```
 
+**Warum wichtig**
+- Der Proxy entkoppelt externe API-Pfade von internen Service-Pfaden und ermoeglicht saubere Migrationen.
+
 ---
 
 ## Medium
@@ -95,7 +129,7 @@ curl http://localhost:8080/demo/a
 **Datei**
 - `proxy/nginx.conf`
 
-**Muss**
+**Schritte (Muss)**
 - Mindestens setzen:
   - `X-Content-Type-Options: nosniff`
   - `X-Frame-Options: DENY`
@@ -104,15 +138,24 @@ curl http://localhost:8080/demo/a
   - `Cross-Origin-Opener-Policy: same-origin`
   - `Cross-Origin-Resource-Policy: same-origin`
 - Optional (Bonus): `Content-Security-Policy` fuer statische Seiten (mit Inline-Styles bewusst beruecksichtigen)
+- Deployen mit `./scripts/lab.sh proxy-reload`.
 
-**Warum wichtig**
+**Fallstrick (`add_header`-Vererbung)**
-- Diese Header reduzieren typische Browser-Angriffsvektoren und gehoeren zu Security-Baselines.
+- Header am besten **einmal im `server {}`-Block** setzen, dann gelten sie fuer alle Locations.
+- Achtung: Sobald in einem `location {}`-Block **ein** `add_header` steht, verwirft Nginx in dieser Location **alle** `add_header` aus dem `server`-Block. Dann muessen sie dort wiederholt werden. Pruefen mit `curl -I` direkt auf der jeweiligen Route.
+
+**Zielzustand / Akzeptanz**
+- `curl -I http://localhost:8080/` zeigt alle geforderten Security-Header in der Antwort.
 
 **Done-Check**
 ```bash
 curl -I http://localhost:8080/
+# -> zeigt X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, COOP, CORP
 ```
 
+**Warum wichtig**
+- Diese Header reduzieren typische Browser-Angriffsvektoren und gehoeren zu Security-Baselines.
+
 ### 5) Interne Route absichern
 
 **Ziel**
@@ -121,25 +164,29 @@ curl -I http://localhost:8080/
 **Datei**
 - `proxy/nginx.conf`
 
-**Muss**
+**Schritte (Muss)**
 - Route `/internal/status` bauen.
 - Nur `127.0.0.1` erlauben, alle anderen verbieten.
-
+- Deployen mit `./scripts/lab.sh proxy-reload`.
-**Warum wichtig**
-- Nicht jeder Endpoint soll oeffentlich sein; Zugriffskontrolle direkt am Proxy ist oft die erste Schutzschicht.
 
 **Wichtiger Hinweis**
 - Host-Request ueber `localhost:8080` kommt aus Docker-Sicht oft **nicht** von `127.0.0.1`.
 
+**Zielzustand / Akzeptanz**
+- Aufruf vom Host liefert `403`; Aufruf von innerhalb des Proxy-Containers (`127.0.0.1`) liefert die Antwort.
+
 **Done-Check**
 ```bash
-# Erwartet typischerweise 403 vom Host (by design)
 curl -i http://localhost:8080/internal/status
+# -> Erwartet typischerweise 403 vom Host (by design)
 
-# Muss innerhalb des Proxy-Containers funktionieren
 ./scripts/compose.sh exec -T reverse-proxy sh -lc "wget -qO- http://127.0.0.1/internal/status"
+# -> "internal ok" (funktioniert nur container-intern)
 ```
 
+**Warum wichtig**
+- Nicht jeder Endpoint soll oeffentlich sein; Zugriffskontrolle direkt am Proxy ist oft die erste Schutzschicht.
+
 ### 6) Logging verbessern
 
 **Ziel**
@@ -148,19 +195,27 @@ curl -i http://localhost:8080/internal/status
 **Datei**
 - `proxy/nginx.conf`
 
-**Muss**
+**Schritte (Muss)**
 - Eigenes `log_format` mit Upstream-Infos anlegen.
 - Access-Log auf das neue Format umstellen.
+- Deployen mit `./scripts/lab.sh proxy-reload`.
 
-**Warum wichtig**
+**Hinweis**
-- Gute Logs verkuerzen Incident- und Debug-Zeit drastisch und sind zentral fuer Betrieb/Security.
+- `log_format` gehoert in den `http {}`-Block (nicht in `server {}` oder `location {}`), sonst startet Nginx mit `"log_format" directive is not allowed here` nicht. `access_log` darf in `http`, `server` oder `location` stehen.
+
+**Zielzustand / Akzeptanz**
+- Nach einem Request erscheint im Log eine Zeile im neuen Format inklusive Upstream-Infos (`upstream=...`, `urt=...`).
 
 **Done-Check**
 ```bash
 curl http://localhost:8080/service/a
 ./scripts/compose.sh logs reverse-proxy
+# -> neue Log-Zeile mit upstream=... und urt=...
 ```
 
+**Warum wichtig**
+- Gute Logs verkuerzen Incident- und Debug-Zeit drastisch und sind zentral fuer Betrieb/Security.
+
 ### 7) Load Balancing konfigurieren
 
 **Ziel**
@@ -170,20 +225,29 @@ curl http://localhost:8080/service/a
 - `docker-compose.yml`
 - `proxy/nginx.conf`
 
-**Muss**
+**Ausgangszustand**
+- `/service/a` zeigt aktuell nur eine Instanz (Backend A). `backends/a2/index.html` liegt bereits im Repo.
+
+**Schritte (Muss)**
 - Zweite Instanz von Backend A (`backend-a2`) anlegen.
 - `upstream backend_a` auf beide Instanzen erweitern.
 - Mehrfach-Requests zeigen, dass beide Instanzen antworten.
+- Deployen mit `./scripts/lab.sh redeploy` (Compose-Aenderung).
 
-**Warum wichtig**
+**Zielzustand / Akzeptanz**
-- Lastverteilung ist eine der wichtigsten Funktionen eines Reverse Proxys fuer Skalierung und Verfuegbarkeit.
+- Bei mehreren Aufrufen von `/service/a` antworten **beide** Instanzen (Round-Robin), also sowohl `Target A` als auch `Target A2`.
 
 **Done-Check (Beispiel)**
 ```bash
 for i in $(seq 1 8); do
-  curl -s http://localhost:8080/service/a | grep -o "Target A2\|Target A"
+  curl -s http://localhost:8080/service/a | grep -o "INSTANCE=[A-Za-z0-9]*"
 done
+# -> Mischung aus "INSTANCE=A" und "INSTANCE=A2" ueber die 8 Requests
 ```
+- Der unsichtbare Marker `<!-- INSTANCE=A -->` bzw. `INSTANCE=A2` steckt im HTML der Backends. `[A-Za-z0-9]*` matched das ganze Token eindeutig (kein Prefix-Problem wie bei `A` vs. `A2`).
+
+**Warum wichtig**
+- Lastverteilung ist eine der wichtigsten Funktionen eines Reverse Proxys fuer Skalierung und Verfuegbarkeit.
 
 ### 8) Response Header Minimization
 
@@ -193,51 +257,64 @@ done
 **Datei**
 - `proxy/nginx.conf`
 
-**Muss**
+**Schritte (Muss)**
 - Mit `proxy_hide_header` mindestens einen durchgereichten Backend-Header ausblenden
   (z. B. `ETag`, `Last-Modified`).
 - Kurz erklaeren, warum weniger Fingerprinting-Infos hilfreich sind.
+- Deployen mit `./scripts/lab.sh proxy-reload`.
 
 **Abgrenzung zu Challenge 4**
 - Challenge 4 setzt aktive Schutz-Header.
 - Challenge 8 entfernt unnoetige Header aus Upstream-Responses.
 
-**Warum wichtig**
+**Zielzustand / Akzeptanz**
-- Weniger Response-Metadaten bedeuten weniger Angriffsoberflaeche fuer Fingerprinting und Reconnaissance.
+- Der gewaehlte Header (z. B. `ETag`) taucht in `curl -I http://localhost:8080/service/a` **nicht mehr** auf, vorher war er sichtbar.
 
 **Done-Check**
 ```bash
 curl -I http://localhost:8080/service/a
+# -> der ausgeblendete Header (z. B. ETag) fehlt jetzt in der Antwort
 ```
 
+**Warum wichtig**
+- Weniger Response-Metadaten bedeuten weniger Angriffsoberflaeche fuer Fingerprinting und Reconnaissance.
+
 ### 9) Debugging Challenge (kaputte Config reparieren)
 
 **Ziel**
 - Fehlerdiagnose in Nginx ueben.
 
+**Ausgangszustand**
+- Eigene `proxy/nginx.conf` ist in Betrieb. `proxy/nginx.broken.conf` enthaelt absichtlich mehrere Fehler.
+
 **Datei**
 - `proxy/nginx.broken.conf`
 
-**Muss**
+**Schritte (Muss)**
+- Zuerst die eigene `proxy/nginx.conf` sichern (z. B. `cp proxy/nginx.conf proxy/nginx.conf.bak`) - diese Challenge ueberschreibt sie.
 - Defekte Config testweise als aktive Config verwenden.
 - Mindestens 2-3 Fehler finden und fixen.
 - Symptome und Diagnoseweg erklaeren.
+- Am Ende die eigene Config wiederherstellen (`cp proxy/nginx.conf.bak proxy/nginx.conf`).
 
 **Erwartete Fehlerarten (Beispiel aus `nginx.broken.conf`)**
 - Upstream-Name passt nicht zum referenzierten Namen in `proxy_pass`.
 - Falscher Upstream-Port (`8080` statt `80`).
 - Fehlender Trailing Slash in `proxy_pass` bei Prefix-Location.
 
-**Warum wichtig**
+**Zielzustand / Akzeptanz**
-- Debugging unter Druck ist Praxisalltag; diese Aufgabe trainiert systematisches Vorgehen mit Logs und Config-Tests.
+- Nach den Fixes liefern `/service/a` und `/service/b` wieder ihre Backends; Nginx startet ohne Config-Fehler.
 
 **Done-Check**
 ```bash
-curl http://localhost:8080/service/a
+curl http://localhost:8080/service/a   # -> "Reverse Proxy Target A"
-curl http://localhost:8080/service/b
+curl http://localhost:8080/service/b   # -> "Reverse Proxy Target B"
 ./scripts/compose.sh logs reverse-proxy
 ```
 
+**Warum wichtig**
+- Debugging unter Druck ist Praxisalltag; diese Aufgabe trainiert systematisches Vorgehen mit Logs und Config-Tests.
+
 ---
 
 ## Hard (TLS)
@@ -247,23 +324,40 @@ curl http://localhost:8080/service/b
 **Ziel**
 - Eigene CA + Server-Zertifikat fuer `localhost` erstellen.
 
+**Ausgangszustand**
+- Stack laeuft auf HTTP (`8080`). Noch kein TLS, kein Port `8443`.
+- `easy-rsa` und `openssl` sind installiert (siehe `challenges/easyrsa-hints.md`).
+
 **Dateien**
-- `docker-compose.yml`
+- `docker-compose.yml` (Port `8443:443` + Cert-Volume)
-- `proxy/nginx.conf`
+- `proxy/nginx.conf` (TLS-Serverblock)
+- `certs/easyrsa/*` (PKI), `certs/live/*` (Runtime-Cert + Key)
 
-**Muss**
+**Schritte (Muss)**
-- Zertifikat fuer `localhost` erstellen.
+- CA + Server-Zertifikat fuer `localhost` mit SAN erstellen (`--subject-alt-name="DNS:localhost,IP:127.0.0.1"`).
-- Proxy auf `443` erweitern (z. B. `8443:443`).
+- Nur Runtime-Cert + Key bereitstellen (nicht die ganze PKI mounten).
-- Root-CA importieren und ohne `-k` testen.
+- Proxy auf `443` erweitern (Mapping `8443:443`) und TLS in Nginx aktivieren.
+- Mit `./scripts/lab.sh redeploy` deployen (Compose-Aenderung -> Container-Neustart noetig).
+- Root-CA in den System-Trust-Store importieren.
 
-**Warum wichtig**
+**Zielzustand / Akzeptanz**
-- TLS korrekt einzurichten ist Basis fuer Vertraulichkeit, Integritaet und Vertrauensaufbau im Netzwerk.
+- `curl https://localhost:8443/service/a` liefert Backend A **ohne** `-k` (CA wird vertraut).
+- Kein SAN-/Hostname-Fehler.
 
 **Done-Check**
 ```bash
 curl https://localhost:8443/service/a
+# Erwartet: HTML von Backend A, KEIN "SSL certificate problem"
+# Falls CA noch nicht global importiert:
+curl --cacert certs/easyrsa/pki/ca.crt https://localhost:8443/service/a
 ```
 
+**Warum wichtig**
+- TLS korrekt einzurichten ist Basis fuer Vertraulichkeit, Integritaet und Vertrauensaufbau im Netzwerk.
+
+**Haeufigster Blocker**
+- Ohne SAN scheitert curl mit `no alternative certificate subject name matches target host name` -> beim Signieren `--subject-alt-name` setzen (Details in `challenges/easyrsa-hints.md`).
+
 ### 11) HTTP -> HTTPS Redirect
 
 **Voraussetzung**
@@ -273,21 +367,29 @@ curl https://localhost:8443/service/a
 **Ziel**
 - HTTP sauber auf HTTPS umlenken.
 
+**Ausgangszustand**
+- Aus Challenge 10: HTTPS laeuft auf `8443`, HTTP auf `8080` liefert noch direkt Inhalte.
+
 **Datei**
 - `proxy/nginx.conf`
 
-**Muss**
+**Schritte (Muss)**
-- HTTP Requests auf HTTPS redirecten.
+- HTTP Requests auf HTTPS redirecten (`return 301 https://$host:8443$request_uri;`).
 - `/healthz` darf optional auf HTTP bleiben.
+- Deployen mit `./scripts/lab.sh proxy-reload` (reine `nginx.conf`-Aenderung).
 
-**Warum wichtig**
+**Zielzustand / Akzeptanz**
-- Redirect erzwingt verschluesselten Zugriff und verhindert versehentliche Nutzung unsicherer HTTP-Endpunkte.
+- HTTP-Aufrufe auf `8080` antworten mit `301` und `Location: https://localhost:8443/...`.
 
 **Done-Check**
 ```bash
 curl -I http://localhost:8080/service/a
+# Erwartet: HTTP/1.1 301 ... und Location: https://localhost:8443/service/a
 ```
 
+**Warum wichtig**
+- Redirect erzwingt verschluesselten Zugriff und verhindert versehentliche Nutzung unsicherer HTTP-Endpunkte.
+
 ### 12) TLS Haertung + Chain Check + HSTS
 
 **Voraussetzung**
@@ -300,23 +402,39 @@ curl -I http://localhost:8080/service/a
 **Datei**
 - `proxy/nginx.conf`
 
-**Muss**
+**Ausgangszustand**
-- TLS auf 1.2/1.3 beschraenken.
+- Aus Challenge 10+11: HTTPS auf `8443` laeuft, HTTP wird umgeleitet. TLS ist aber noch ungehaertet (keine Protokoll-Beschraenkung, kein HSTS).
+
+**Schritte (Muss)**
+- TLS auf 1.2/1.3 beschraenken (`ssl_protocols TLSv1.2 TLSv1.3;`).
 - HSTS setzen (`Strict-Transport-Security`).
 - Zertifikatskette pruefen und kurz erklaeren.
-
+- Deployen mit `./scripts/lab.sh proxy-reload`.
-**Warum wichtig**
-- Reines "HTTPS an" reicht nicht: erst Haertung + HSTS reduzieren Downgrade- und Fehlkonfigurationsrisiken.
 
 **Hinweis**
 - Im HTTP-Basissetup ist HSTS absichtlich **noch nicht** aktiv. Das ist Teil der Aufgabe.
 
+**Warnung (HSTS-Falle im Browser)**
+- HSTS merkt sich der Browser **host-weit** (`localhost`), nicht pro Port. Nach einem Besuch von `https://localhost:8443` erzwingt der Browser `https` auch fuer `http://localhost:8080` -> das HTTP-Lab scheint dann "kaputt".
+- Zum Pruefen daher `curl` nutzen (curl speichert HSTS nicht).
+- Falls der Browser haengt: HSTS fuer `localhost` zuruecksetzen (Chrome: `chrome://net-internals/#hsts` -> "Delete domain security policies" -> `localhost`).
+- `max-age` ist im Lab bewusst kurz (1h), damit der Effekt von selbst verfaellt.
+
+**Zielzustand / Akzeptanz**
+- `curl -I` zeigt den `Strict-Transport-Security`-Header.
+- `openssl s_client` verhandelt TLSv1.2 oder TLSv1.3 und endet mit `Verify return code: 0 (ok)`.
+
 **Done-Check**
 ```bash
 curl -I https://localhost:8443/service/a
+# -> enthaelt: Strict-Transport-Security: max-age=3600; includeSubDomains
 openssl s_client -connect localhost:8443 -servername localhost
+# -> Protocol: TLSv1.3 (oder 1.2), Verify return code: 0 (ok)
 ```
 
+**Warum wichtig**
+- Reines "HTTPS an" reicht nicht: erst Haertung + HSTS reduzieren Downgrade- und Fehlkonfigurationsrisiken.
+
 ---
 
 ## Bonus Expert
@@ -326,14 +444,18 @@ openssl s_client -connect localhost:8443 -servername localhost
 **Ziel**
 - Nachweisbar zeigen, was im Klartext sichtbar ist und was durch TLS geschuetzt wird.
 
-**Muss**
+**Ausgangszustand**
+- HTTPS laeuft (Challenge 10), `8080` und `8443` sind erreichbar. Wireshark/tshark ist installiert (siehe `challenges/wireshark-hints.md`).
+
+**Schritte (Muss)**
 - HTTP auf `8080` mitschneiden.
 - HTTPS auf `8443` mitschneiden.
 - `ClientHello`, `ServerHello`, `Certificate` markieren.
 - Technisch erklaeren, warum HTTP lesbar ist und HTTPS ohne Keys nicht.
 
-**Warum wichtig**
+**Zielzustand / Akzeptanz**
-- Wer den Unterschied auf Paketebene gesehen hat, versteht TLS nicht nur theoretisch, sondern praktisch.
+- HTTP-Mitschnitt: Pfad und Header sind im Klartext lesbar (Follow Stream).
+- HTTPS-Mitschnitt: nur der TLS-Handshake ist sichtbar, die Nutzdaten sind ohne Key nicht lesbar.
 
 **Vorgehen (empfohlen)**
 1. Capture auf passendem Interface starten (lokal meist `lo`).
@@ -347,6 +469,9 @@ openssl s_client -connect localhost:8443 -servername localhost
 **Done-Check**
 - 3-4 Screenshots + 3-5 Bulletpoints Auswertung.
 
+**Warum wichtig**
+- Wer den Unterschied auf Paketebene gesehen hat, versteht TLS nicht nur theoretisch, sondern praktisch.
+
 **Typische Fehler**
 - falsches Interface gewaehlt
 - HTTPS noch nicht korrekt aktiv

challenges/easyrsa-hints.md

@@ -36,9 +36,11 @@ cd certs/easyrsa
 
 ```bash
 ./easyrsa gen-req localhost nopass
-./easyrsa sign-req server localhost
+./easyrsa --subject-alt-name="DNS:localhost,IP:127.0.0.1" sign-req server localhost
 ```
 
+Wichtig: Das `--subject-alt-name` ist nicht optional. Moderne Clients (curl, Browser) ignorieren den CN und pruefen ausschliesslich den SAN. Ohne SAN scheitert `curl https://localhost:8443` trotz korrekt importierter CA mit `no alternative certificate subject name matches target host name`.
+
 ## 5) Nur Runtime-Zertifikate bereitstellen (nicht komplette PKI mounten)
 
 Nutze fuer den Container nur die benoetigten Laufzeitdateien:
@@ -101,7 +103,7 @@ server {
   ssl_certificate /etc/nginx/certs/localhost.crt;
   ssl_certificate_key /etc/nginx/certs/localhost.key;
   ssl_protocols TLSv1.2 TLSv1.3;
-  add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
+  add_header Strict-Transport-Security "max-age=3600; includeSubDomains" always;
 
   add_header X-Content-Type-Options "nosniff" always;
   add_header X-Frame-Options "DENY" always;
@@ -122,6 +124,10 @@ server {
 
 ## 6) Root-CA importieren (Trust Store)
 
+Wichtig: In den Trust-Store **der Umgebung importieren, in der du testest**.
+- Test mit `curl` aus **WSL** (der Standardweg im Workshop): in den **Linux**-Trust-Store importieren -> Ubuntu/Debian-Befehle unten.
+- Test im **Windows-Browser**: zusaetzlich der Windows-Import (`certutil`).
+
 Fedora:
 
 ```bash

challenges/wireshark-hints.md

@@ -22,6 +22,20 @@ sudo apt install -y wireshark tshark
 - Linux lokal: meist `lo` (Loopback) fuer `localhost`
 - Docker-Welt: ggf. `docker0` bzw. Bridge-Interface
 
+**Windows (Docker Desktop + WSL) - empfohlener Weg:**
+
+- Capture **innerhalb WSL** machen, dort verhaelt sich `lo` wie unter Linux. Sowohl der `curl`-Request als auch der Mitschnitt laufen im WSL-Terminal:
+
+```bash
+# Terminal 1 (WSL): Mitschnitt starten
+sudo tshark -i lo -f "tcp port 8080"
+# Terminal 2 (WSL): Request senden
+curl http://localhost:8080/service/a
+```
+
+- Natives Windows-Wireshark kann `localhost` nur ueber den npcap-Adapter "Adapter for loopback traffic capture" mitschneiden, und Docker-Desktop-Portforwarding macht das unzuverlaessig. Fuer den Workshop daher in WSL bleiben.
+- Wireshark-GUI unter WSL braucht WSLg (Windows 11) oder ein X-Server; einfacher ist `tshark` (CLI) plus spaeter `.pcap` in der Wireshark-GUI oeffnen (`tshark -w mitschnitt.pcap ...`).
+
 ## 3) HTTP zuerst (Klartext)
 
 1. Mitschnitt starten
@@ -85,12 +99,14 @@ tls.handshake.type == 11
 
 ## 6) Optional: TLS in Wireshark entschluesseln
 
-1. Vor Browser-Start setzen:
+1. Vor Browser-Start setzen (WSL/bash):
 
 ```bash
 export SSLKEYLOGFILE="$HOME/sslkeys.log"
 ```
 
+In PowerShell waere es stattdessen `$env:SSLKEYLOGFILE = "$HOME\sslkeys.log"` - der einfachste Weg ist aber, alles in WSL zu machen.
+
 2. Browser aus derselben Shell starten und HTTPS-Request erzeugen.
 3. In Wireshark unter TLS-Preferences `sslkeys.log` als Key Log File setzen.
 4. Mitschnitt erneut laden.

docker-compose.yml

@@ -8,7 +8,7 @@ services:
       - backend-a
       - backend-b
     ports:
-      - "${HTTP_PORT:-8080}:80"
+      - "8080:80"
     volumes:
       - ./proxy/nginx.conf:/etc/nginx/nginx.conf:ro,z
       - ./proxy/html:/usr/share/nginx/html:ro,z

proxy/html/challenges.html

@@ -176,6 +176,12 @@
         </div>
       </section>
 
+      <section class="panel">
+        <h2>Wo laufen die Kommandos? (Windows)</h2>
+        <p>Stack steuern geht aus PowerShell (<code>scripts/workshop.ps1</code>) <b>oder</b> WSL. Aber <b>alle</b> Test-Kommandos (<code>curl</code>, <code>openssl</code>, <code>grep</code>, <code>for</code>-Schleifen, <code>./scripts/compose.sh</code>) laufen im <b>WSL-Terminal (bash)</b>.</p>
+        <p><span class="kw">Warnung:</span> In PowerShell ist <code>curl</code> ein Alias fuer <code>Invoke-WebRequest</code> und versteht <code>-I</code>/<code>-k</code>/<code>--cacert</code> nicht. Immer im WSL-Terminal testen.</p>
+      </section>
+
       <section class="panel">
         <h2>Abgabe-Format</h2>
         <ul>
@@ -196,8 +202,9 @@
             <li>Welche <code>location</code> matched <code>/service/a</code>?</li>
             <li>Welcher <code>upstream</code> wird verwendet?</li>
           </ul>
-          <pre><code>curl http://localhost:8080/service/a
+          <p><span class="kw">Zielzustand:</span> Du kannst Location &rarr; Upstream &rarr; Backend benennen und begruenden, warum A und B unterschiedlich antworten.</p>
-curl http://localhost:8080/service/b</code></pre>
+          <pre><code>curl http://localhost:8080/service/a   # -&gt; "Target A"
+curl http://localhost:8080/service/b   # -&gt; "Target B"</code></pre>
         </details>
 
         <details id="challenge-2-backend-c">
@@ -205,16 +212,18 @@ curl http://localhost:8080/service/b</code></pre>
           <p><span class="kw">Muss:</span> Compose-Service + Upstream + Route <code>/service/c</code>.</p>
           <p><span class="kw">Zusatz:</span> <code>backends/c/index.html</code> ist vorhanden und darf angepasst werden.</p>
           <p><span class="kw">Warum wichtig:</span> Neue Services kommen laufend dazu; Erweiterungen ohne Seiteneffekte sind Praxisalltag.</p>
-          <pre><code>curl http://localhost:8080/service/c
+          <p><span class="kw">Zielzustand:</span> <code>/service/c</code> liefert Backend C; A und B laufen unveraendert weiter.</p>
-curl http://localhost:8080/service/a
+          <pre><code>curl http://localhost:8080/service/c   # -&gt; "Reverse Proxy Target C"
-curl http://localhost:8080/service/b</code></pre>
+curl http://localhost:8080/service/a   # -&gt; weiterhin "Target A"
+curl http://localhost:8080/service/b   # -&gt; weiterhin "Target B"</code></pre>
         </details>
 
         <details>
           <summary><span class="badge easy">Easy</span> 3) Eigene Route /demo/a</summary>
           <p><span class="kw">Muss:</span> Alias-Route bauen, die auf Backend A fuehrt.</p>
           <p><span class="kw">Warum wichtig:</span> Der Proxy entkoppelt externe Pfade von internen Backend-Implementierungen.</p>
-          <pre><code>curl http://localhost:8080/demo/a</code></pre>
+          <p><span class="kw">Zielzustand:</span> <code>/demo/a</code> liefert dieselbe Antwort wie <code>/service/a</code>.</p>
+          <pre><code>curl http://localhost:8080/demo/a   # -&gt; "Target A"</code></pre>
         </details>
       </section>
 
@@ -226,7 +235,9 @@ curl http://localhost:8080/service/b</code></pre>
           <p>Setze mindestens <code>nosniff</code>, <code>DENY</code>, <code>strict-origin-when-cross-origin</code>, <code>Permissions-Policy</code>, <code>COOP</code>, <code>CORP</code>.</p>
           <p><span class="kw">Optional:</span> CSP fuer statische Seiten.</p>
           <p><span class="kw">Warum wichtig:</span> Diese Header reduzieren konkrete Browser-Angriffsvektoren und gehoeren zur Security-Baseline.</p>
-          <pre><code>curl -I http://localhost:8080/</code></pre>
+          <p><span class="kw">Fallstrick:</span> Header im <code>server {}</code>-Block setzen. Sobald in einem <code>location {}</code> ein <code>add_header</code> steht, verwirft Nginx dort <b>alle</b> Server-Header &rarr; dann erneut setzen.</p>
+          <p><span class="kw">Zielzustand:</span> <code>curl -I /</code> zeigt alle geforderten Security-Header.</p>
+          <pre><code>curl -I http://localhost:8080/   # -&gt; nosniff, DENY, Referrer-Policy, Permissions-Policy, COOP, CORP</code></pre>
         </details>
 
         <details>
@@ -234,25 +245,29 @@ curl http://localhost:8080/service/b</code></pre>
           <p><span class="kw">Muss:</span> <code>/internal/status</code> nur fuer <code>127.0.0.1</code>.</p>
           <p><span class="kw">Wichtig:</span> Host-Request zeigt typischerweise 403 (Docker-Netzwerk).</p>
           <p><span class="kw">Warum wichtig:</span> Nicht jeder Endpoint darf oeffentlich erreichbar sein; Netzsegmentierung beginnt oft am Proxy.</p>
-          <pre><code>curl -i http://localhost:8080/internal/status
+          <p><span class="kw">Zielzustand:</span> Host &rarr; 403; container-intern (127.0.0.1) &rarr; Antwort.</p>
-./scripts/compose.sh exec -T reverse-proxy sh -lc "wget -qO- http://127.0.0.1/internal/status"</code></pre>
+          <pre><code>curl -i http://localhost:8080/internal/status   # -&gt; 403 (vom Host)
+./scripts/compose.sh exec -T reverse-proxy sh -lc "wget -qO- http://127.0.0.1/internal/status"   # -&gt; "internal ok"</code></pre>
         </details>
 
         <details>
           <summary><span class="badge medium">Medium</span> 6) Logging verbessern</summary>
           <p>Eigenes <code>log_format</code> mit Upstream-Infos einbauen.</p>
+          <p><span class="kw">Hinweis:</span> <code>log_format</code> gehoert in den <code>http {}</code>-Block, sonst startet Nginx nicht.</p>
           <p><span class="kw">Warum wichtig:</span> Ohne brauchbare Logs dauert Fehleranalyse deutlich laenger und Incident-Response wird unzuverlaessig.</p>
+          <p><span class="kw">Zielzustand:</span> Log-Zeile im neuen Format mit Upstream-Infos (<code>upstream=...</code>, <code>urt=...</code>).</p>
           <pre><code>curl http://localhost:8080/service/a
-./scripts/compose.sh logs reverse-proxy</code></pre>
+./scripts/compose.sh logs reverse-proxy   # -&gt; neue Zeile mit upstream=... urt=...</code></pre>
         </details>
 
         <details>
           <summary><span class="badge medium">Medium</span> 7) Load Balancing</summary>
           <p>Zweite Instanz von Backend A (<code>backend-a2</code>) einbauen und Round-Robin zeigen.</p>
           <p><span class="kw">Warum wichtig:</span> Lastverteilung ist Kernnutzen eines Reverse Proxys fuer Skalierung und Verfuegbarkeit.</p>
+          <p><span class="kw">Zielzustand:</span> Ueber mehrere Requests antworten <b>beide</b> Instanzen (Mischung aus A und A2).</p>
           <pre><code>for i in $(seq 1 8); do
-  curl -s http://localhost:8080/service/a | grep -o "Target A2\|Target A"
+  curl -s http://localhost:8080/service/a | grep -o "INSTANCE=[A-Za-z0-9]*"
-done</code></pre>
+done   # -&gt; Mischung aus "INSTANCE=A" und "INSTANCE=A2"</code></pre>
         </details>
 
         <details>
@@ -260,16 +275,19 @@ done</code></pre>
           <p>Mindestens einen Backend-Response-Header per <code>proxy_hide_header</code> ausblenden.</p>
           <p><span class="kw">Abgrenzung zu #4:</span> #4 setzt Schutz-Header, #8 entfernt unnoetige Header aus Upstream-Responses.</p>
           <p><span class="kw">Warum wichtig:</span> Weniger preisgegebene Metadaten erschweren Fingerprinting und zielgerichtete Angriffe.</p>
-          <pre><code>curl -I http://localhost:8080/service/a</code></pre>
+          <p><span class="kw">Zielzustand:</span> Der ausgeblendete Header (z. B. <code>ETag</code>) fehlt jetzt in der Antwort.</p>
+          <pre><code>curl -I http://localhost:8080/service/a   # -&gt; ETag/Last-Modified nicht mehr vorhanden</code></pre>
         </details>
 
         <details>
           <summary><span class="badge medium">Medium</span> 9) Debugging Challenge</summary>
           <p>Mit <code>proxy/nginx.broken.conf</code> arbeiten, Fehler finden und reparieren.</p>
+          <p><span class="kw">Zuerst sichern:</span> diese Challenge ueberschreibt deine <code>nginx.conf</code> &rarr; vorher <code>cp proxy/nginx.conf proxy/nginx.conf.bak</code>, am Ende zurueckkopieren.</p>
           <p><span class="kw">Warum wichtig:</span> In der Praxis geht es oft um Diagnose unter Zeitdruck, nicht nur um Greenfield-Konfiguration.</p>
           <p><span class="kw">Typische Fehler in der kaputten Datei:</span> Upstream-Name-Mismatch, falscher Port, fehlender Trailing Slash in <code>proxy_pass</code>.</p>
-          <pre><code>curl http://localhost:8080/service/a
+          <p><span class="kw">Zielzustand:</span> Nach den Fixes liefern A und B wieder ihre Backends; Nginx startet fehlerfrei.</p>
-curl http://localhost:8080/service/b
+          <pre><code>curl http://localhost:8080/service/a   # -&gt; "Target A"
+curl http://localhost:8080/service/b   # -&gt; "Target B"
 ./scripts/compose.sh logs reverse-proxy</code></pre>
         </details>
       </section>
@@ -280,22 +298,27 @@ curl http://localhost:8080/service/b
         <details>
           <summary><span class="badge hard">Hard</span> 10) HTTPS von 0 (Easy-RSA)</summary>
           <p>Zertifikat fuer <code>localhost</code>, Port <code>8443:443</code>, Root-CA importiert.</p>
+          <p><span class="kw">Wichtig:</span> Der neue Port ist eine Compose-Aenderung &rarr; mit <code>./scripts/lab.sh redeploy</code> deployen, nicht nur <code>./scripts/lab.sh proxy-reload</code>.</p>
           <p><span class="kw">Warum wichtig:</span> TLS-Grundaufbau ist Voraussetzung fuer vertrauliche und manipulationssichere Kommunikation.</p>
-          <pre><code>curl https://localhost:8443/service/a</code></pre>
+          <p><span class="kw">Zielzustand:</span> Aufruf liefert Backend A <b>ohne</b> <code>-k</code> (kein SAN-/Zertifikatsfehler). Zertifikat mit SAN signieren!</p>
+          <pre><code>curl https://localhost:8443/service/a   # -&gt; Backend A, KEIN "SSL certificate problem"</code></pre>
         </details>
 
         <details>
           <summary><span class="badge hard">Hard</span> 11) HTTP -&gt; HTTPS Redirect</summary>
           <p><span class="kw">Voraussetzung:</span> Challenge 10 abgeschlossen. Bestehende Config weiterverwenden.</p>
           <p><span class="kw">Warum wichtig:</span> Redirect verhindert unabsichtliche Klartext-Nutzung und erzwingt den sicheren Transport.</p>
-          <pre><code>curl -I http://localhost:8080/service/a</code></pre>
+          <p><span class="kw">Zielzustand:</span> HTTP auf <code>8080</code> antwortet mit <code>301</code> und <code>Location: https://localhost:8443/...</code>.</p>
+          <pre><code>curl -I http://localhost:8080/service/a   # -&gt; 301, Location: https://localhost:8443/service/a</code></pre>
         </details>
 
         <details>
           <summary><span class="badge hard">Hard</span> 12) TLS Haertung + Chain + HSTS</summary>
           <p><span class="kw">Voraussetzung:</span> Challenge 10 und 11 abgeschlossen. Gleiche Config weiter erweitern.</p>
           <p><span class="kw">Warum wichtig:</span> Erst Haertung + HSTS reduzieren Downgrade-Risiken und sorgen fuer dauerhaft sichere Clients.</p>
-          <pre><code>curl -I https://localhost:8443/service/a
+          <p><span class="kw">Warnung (HSTS-Falle):</span> Der Browser merkt sich HSTS host-weit fuer <code>localhost</code> (nicht pro Port). Nach <code>https://localhost:8443</code> wird auch <code>http://localhost:8080</code> auf https erzwungen. Zum Testen <code>curl</code> nutzen; Browser-HSTS ggf. unter <code>chrome://net-internals/#hsts</code> fuer <code>localhost</code> loeschen. <code>max-age</code> ist im Lab bewusst kurz (1h).</p>
+          <p><span class="kw">Zielzustand:</span> <code>curl -I</code> zeigt <code>Strict-Transport-Security</code>; <code>s_client</code> verhandelt TLSv1.2/1.3 mit <code>Verify return code: 0 (ok)</code>.</p>
+          <pre><code>curl -I https://localhost:8443/service/a   # -&gt; enthaelt Strict-Transport-Security
 openssl s_client -connect localhost:8443 -servername localhost</code></pre>
         </details>
       </section>
@@ -313,6 +336,7 @@ openssl s_client -connect localhost:8443 -servername localhost</code></pre>
             <li>3-5 Bulletpoints: was ist sichtbar, was ist geschuetzt?</li>
           </ol>
           <p><span class="kw">Optional:</span> TLS Decrypt mit <code>SSLKEYLOGFILE</code>.</p>
+          <p><span class="kw">Zielzustand:</span> HTTP-Mitschnitt zeigt Pfad/Header im Klartext; HTTPS zeigt nur den Handshake, Nutzdaten ohne Key nicht lesbar.</p>
           <p><span class="kw">Abgabe:</span> mind. 3 Screenshots + technische Interpretation.</p>
         </details>
       </section>

proxy/html/hints.html

@@ -149,14 +149,14 @@
           </article>
           <article class="card">
             <h3>Neu deployen</h3>
-            <pre><code>make redeploy
+            <pre><code>./scripts/lab.sh redeploy
-make proxy-reload</code></pre>
+./scripts/lab.sh proxy-reload</code></pre>
             <p>PowerShell: <code>./scripts/workshop.ps1 -Action redeploy</code></p>
           </article>
           <article class="card">
             <h3>Reset</h3>
-            <pre><code>make reset
+            <pre><code>./scripts/lab.sh reset
-make bootstrap</code></pre>
+./scripts/lab.sh bootstrap</code></pre>
             <p>PowerShell: <code>./scripts/workshop.ps1 -Action reset</code></p>
           </article>
         </div>
@@ -173,7 +173,7 @@ cd certs/easyrsa
 ./easyrsa init-pki
 ./easyrsa build-ca nopass
 ./easyrsa gen-req localhost nopass
-./easyrsa sign-req server localhost</code></pre>
+./easyrsa --subject-alt-name="DNS:localhost,IP:127.0.0.1" sign-req server localhost</code></pre>
             <p>Nur Runtime-Certs mounten (z. B. <code>certs/live</code>), nicht die komplette PKI.</p>
           </article>
           <article class="card">

proxy/html/index.html

@@ -104,7 +104,7 @@
       <section class="panel">
         <h1>HTL Reverse Proxy & TLS Lab</h1>
         <p>
-          Basis läuft mit HTTP. Ziel im Workshop: Reverse Proxy verstehen und HTTPS/TLS manuell
+          Basis laeuft mit HTTP. Ziel im Workshop: Reverse Proxy verstehen und HTTPS/TLS manuell
           aufbauen.
         </p>
         <div class="top-links">
@@ -125,6 +125,10 @@
           <li><code>curl http://localhost:8080/service/b</code></li>
           <li><code>./scripts/compose.sh ps</code></li>
         </ul>
+        <p>
+          <b>Windows:</b> Diese Kommandos im <b>WSL-Terminal (bash)</b> ausfuehren, nicht in PowerShell
+          (dort ist <code>curl</code> ein Alias fuer <code>Invoke-WebRequest</code>).
+        </p>
       </section>
 
       <section class="panel">

proxy/html/solutions.html

@@ -165,7 +165,7 @@
       <section class="panel">
         <h1>Solutions Board (detailliert)</h1>
         <p>Hier stehen absichtlich konkrete Musterloesungen mit Snippets, Checks und typischen Stolperfallen.</p>
-        <p><span class="kw">Workflow:</span> Nach jeder Konfig-Aenderung mindestens <code>make proxy-reload</code>, bei Compose-Aenderungen <code>make redeploy</code>.</p>
+        <p><span class="kw">Workflow:</span> Nach jeder Konfig-Aenderung mindestens <code>./scripts/lab.sh proxy-reload</code>, bei Compose-Aenderungen <code>./scripts/lab.sh redeploy</code>.</p>
         <div class="top-links">
           <a class="pill" href="/">Startseite</a>
           <a class="pill" href="/challenges.html">Challenges</a>
@@ -215,7 +215,7 @@ location /service/c {
         </details>
 
         <details>
-          <summary><span class="badge easy">Easy</span> 3) Rewrite Route</summary>
+          <summary><span class="badge easy">Easy</span> 3) Alias-Route /demo/a</summary>
           <p><span class="kw">Dateien:</span> <code>proxy/nginx.conf</code></p>
           <p><span class="kw">Commands noetig:</span> ja</p>
           <pre><code>location = /demo/a {
@@ -238,6 +238,7 @@ add_header Referrer-Policy "strict-origin-when-cross-origin" always;
 add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
 add_header Cross-Origin-Opener-Policy "same-origin" always;
 add_header Cross-Origin-Resource-Policy "same-origin" always;</code></pre>
+          <p><span class="kw">Platzierung:</span> in den <code>server {}</code>-Block, damit alle Locations sie erben. Sobald eine Location ein eigenes <code>add_header</code> hat, verwirft Nginx dort die Server-Header und sie muessen wiederholt werden.</p>
           <p><span class="kw">Optional CSP (statisch, inline styles erlaubt):</span></p>
           <pre><code>add_header Content-Security-Policy "default-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; object-src 'none'; base-uri 'none'; frame-ancestors 'none'" always;</code></pre>
           <p><span class="kw">Check:</span> <code>curl -I http://localhost:8080/</code></p>
@@ -262,6 +263,7 @@ add_header Cross-Origin-Resource-Policy "same-origin" always;</code></pre>
           <summary><span class="badge medium">Medium</span> 6) Logging verbessern</summary>
           <p><span class="kw">Dateien:</span> <code>proxy/nginx.conf</code></p>
           <p><span class="kw">Commands noetig:</span> ja</p>
+          <p><span class="kw">Platzierung:</span> <code>log_format</code> muss in den <code>http {}</code>-Block (sonst startet Nginx nicht). <code>access_log</code> darf in <code>http</code>, <code>server</code> oder <code>location</code>.</p>
           <pre><code>log_format workshop '$remote_addr - $request '
                    'status=$status upstream=$upstream_addr '
                    'rt=$request_time urt=$upstream_response_time';
@@ -289,8 +291,9 @@ access_log /var/log/nginx/access.log workshop;</code></pre>
 }</code></pre>
           <p><span class="kw">Check:</span></p>
           <pre><code>for i in $(seq 1 8); do
-  curl -s http://localhost:8080/service/a | grep -o "Target A2\|Target A"
+  curl -s http://localhost:8080/service/a | grep -o "INSTANCE=[A-Za-z0-9]*"
 done</code></pre>
+          <p><span class="kw">Marker:</span> Backend A/A2 enthalten unsichtbar <code>&lt;!-- INSTANCE=A --&gt;</code> bzw. <code>INSTANCE=A2</code>. <code>[A-Za-z0-9]*</code> matched das ganze Token (kein Prefix-Problem A vs. A2).</p>
         </details>
 
         <details>
@@ -298,6 +301,7 @@ done</code></pre>
           <p><span class="kw">Dateien:</span> <code>proxy/nginx.conf</code></p>
           <p><span class="kw">Commands noetig:</span> ja</p>
           <p><span class="kw">Abgrenzung zu #4:</span> #4 fuegt Schutz-Header hinzu, #8 entfernt unnoetige Upstream-Metadaten.</p>
+          <p><span class="kw">Gut zu wissen:</span> <code>proxy_hide_header</code> ist kein <code>add_header</code> &rarr; es loest die Vererbungsfalle aus #4 nicht aus. Die Server-Header bleiben in dieser Location erhalten.</p>
           <pre><code>location /service/a {
   proxy_pass http://backend_a/;
   proxy_hide_header ETag;
@@ -310,10 +314,14 @@ done</code></pre>
           <summary><span class="badge medium">Medium</span> 9) Debugging Challenge</summary>
           <p><span class="kw">Dateien:</span> <code>proxy/nginx.broken.conf</code>, <code>proxy/nginx.conf</code></p>
           <p><span class="kw">Commands noetig:</span> ja</p>
-          <p><span class="kw">Ablauf:</span> Kopiere testweise <code>proxy/nginx.broken.conf</code> auf <code>proxy/nginx.conf</code>, behebe die Fehler und stelle danach die funktionierende Konfiguration wieder her.</p>
+          <p><span class="kw">Ablauf:</span> Zuerst die eigene Config sichern (diese Challenge ueberschreibt sie!), dann die kaputte aktivieren, Fehler beheben und am Ende die eigene Config wiederherstellen.</p>
-          <pre><code>cp proxy/nginx.broken.conf proxy/nginx.conf
+          <pre><code>cp proxy/nginx.conf proxy/nginx.conf.bak      # 1. eigene Config sichern
-make proxy-reload
+cp proxy/nginx.broken.conf proxy/nginx.conf   # 2. kaputte aktivieren
-./scripts/compose.sh logs reverse-proxy</code></pre>
+./scripts/lab.sh proxy-reload
+./scripts/compose.sh logs reverse-proxy        # 3. Fehler finden + fixen</code></pre>
+          <p><span class="kw">Am Ende eigene Config zurueck:</span></p>
+          <pre><code>cp proxy/nginx.conf.bak proxy/nginx.conf
+./scripts/lab.sh proxy-reload</code></pre>
           <p><span class="kw">Konkrete Fehler und Fixes:</span></p>
           <ol>
             <li><span class="kw">Upstream-Mismatch:</span> <code>backend_a_typo</code> ist definiert, aber <code>backend_a</code> wird referenziert -> Namen angleichen.</li>
@@ -340,7 +348,7 @@ cd certs/easyrsa
 ./easyrsa init-pki
 ./easyrsa build-ca nopass
 ./easyrsa gen-req localhost nopass
-./easyrsa sign-req server localhost</code></pre>
+./easyrsa --subject-alt-name="DNS:localhost,IP:127.0.0.1" sign-req server localhost</code></pre>
           <p><span class="kw">Compose:</span></p>
           <pre><code>reverse-proxy:
   ports:
@@ -349,6 +357,7 @@ cd certs/easyrsa
   volumes:
     - ./certs/live:/etc/nginx/certs:ro,z</code></pre>
           <p><span class="kw">Wichtig:</span> Nicht die komplette PKI in den Container mounten. Nur Runtime-Zertifikat + Key bereitstellen.</p>
+          <p><span class="kw">Deploy:</span> Port- und Volume-Aenderungen sind Compose-Aenderungen &rarr; <code>./scripts/lab.sh redeploy</code> (nicht <code>./scripts/lab.sh proxy-reload</code>), sonst greift der neue Port nicht.</p>
           <p><span class="kw">Nginx TLS-Pfade:</span> <code>ssl_certificate /etc/nginx/certs/localhost.crt;</code> und <code>ssl_certificate_key /etc/nginx/certs/localhost.key;</code></p>
           <p><span class="kw">Check:</span> <code>curl https://localhost:8443/service/a</code> (ohne <code>-k</code> nach CA-Import)</p>
         </details>
@@ -381,7 +390,7 @@ cd certs/easyrsa
           <p><span class="kw">Commands noetig:</span> ja</p>
           <pre><code>ssl_protocols TLSv1.2 TLSv1.3;
 ssl_prefer_server_ciphers on;
-add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;</code></pre>
+add_header Strict-Transport-Security "max-age=3600; includeSubDomains" always;</code></pre>
           <p><span class="kw">Check:</span></p>
           <pre><code>curl -I https://localhost:8443/service/a
 openssl s_client -connect localhost:8443 -servername localhost</code></pre>

proxy/nginx.tls.example.conf

@@ -39,7 +39,10 @@ http {
     ssl_protocols TLSv1.2 TLSv1.3;
     ssl_prefer_server_ciphers on;
 
-    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
+    # max-age im Lab bewusst kurz (1h). In Produktion eher 1 Jahr (31536000).
+    # includeSubDomains weitet HSTS auf alle Subdomains aus (Produktions-Best-Practice).
+    # Achtung: HSTS bleibt im Browser host-weit haengen -> siehe Warnhinweis in Challenge 12.
+    add_header Strict-Transport-Security "max-age=3600; includeSubDomains" always;
     add_header X-Content-Type-Options "nosniff" always;
     add_header X-Frame-Options "DENY" always;
     add_header Referrer-Policy "strict-origin-when-cross-origin" always;

scripts/bootstrap-unix.sh

@@ -1,36 +0,0 @@
-#!/usr/bin/env bash
-set -euo pipefail
-
-SCRIPT_DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd)"
-PROJECT_ROOT="$(cd -- "$SCRIPT_DIR/.." && pwd)"
-
-cd "$PROJECT_ROOT"
-
-if ! command -v docker >/dev/null 2>&1; then
-  echo "[error] docker nicht gefunden. Bitte Docker installieren (Linux/macOS) oder Docker Desktop + WSL Integration aktivieren."
-  exit 1
-fi
-
-if ! docker info >/dev/null 2>&1; then
-  echo "[error] Docker Daemon nicht erreichbar. Bitte Docker starten."
-  exit 1
-fi
-
-if ! "$SCRIPT_DIR/compose.sh" version >/dev/null 2>&1; then
-  echo "[error] Weder docker compose noch docker-compose verfuegbar."
-  exit 1
-fi
-
-if [[ ! -f .env ]]; then
-  cp .env.example .env
-  echo "[ok] .env aus .env.example erstellt"
-else
-  echo "[skip] .env existiert bereits"
-fi
-
-"$SCRIPT_DIR/compose.sh" up -d --build
-
-echo
-echo "[ok] Workshop-Stack laeuft"
-echo "      Landing Page: http://localhost:8080"
-echo "      Test (backend-a): curl http://localhost:8080/service/a"

scripts/bootstrap-wsl.sh

@@ -1,6 +0,0 @@
-#!/usr/bin/env bash
-set -euo pipefail
-
-SCRIPT_DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd)"
-echo "[warn] scripts/bootstrap-wsl.sh ist deprecated. Nutze bitte scripts/bootstrap.sh"
-"$SCRIPT_DIR/bootstrap-unix.sh"

scripts/bootstrap.sh

@@ -2,4 +2,28 @@
 set -euo pipefail
 
 SCRIPT_DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd)"
-"$SCRIPT_DIR/bootstrap-unix.sh"
+PROJECT_ROOT="$(cd -- "$SCRIPT_DIR/.." && pwd)"
+
+cd "$PROJECT_ROOT"
+
+if ! command -v docker >/dev/null 2>&1; then
+  echo "[error] docker nicht gefunden. Bitte Docker installieren (Linux/macOS) oder Docker Desktop + WSL Integration aktivieren."
+  exit 1
+fi
+
+if ! docker info >/dev/null 2>&1; then
+  echo "[error] Docker Daemon nicht erreichbar. Bitte Docker starten."
+  exit 1
+fi
+
+if ! "$SCRIPT_DIR/compose.sh" version >/dev/null 2>&1; then
+  echo "[error] Weder docker compose noch docker-compose verfuegbar."
+  exit 1
+fi
+
+"$SCRIPT_DIR/compose.sh" up -d --build
+
+echo
+echo "[ok] Workshop-Stack laeuft"
+echo "      Landing Page: http://localhost:8080"
+echo "      Test (backend-a): curl http://localhost:8080/service/a"

scripts/lab.sh

@@ -0,0 +1,27 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+# Zentrale Steuer-Oberflaeche fuer den Workshop-Stack.
+# Eine einzige Quelle der Wahrheit fuer alle Aktionen - der PowerShell-Wrapper
+# (scripts/workshop.ps1) ruft genau dieses Skript in WSL auf.
+
+SCRIPT_DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd)"
+
+usage() {
+  echo "usage: lab.sh {bootstrap|up|redeploy|proxy-reload|down|logs|reset|reset-hard|reset-origin}"
+}
+
+case "${1:-}" in
+  bootstrap)    "$SCRIPT_DIR/bootstrap.sh" ;;
+  up)           "$SCRIPT_DIR/compose.sh" up -d --build ;;
+  redeploy)     "$SCRIPT_DIR/compose.sh" up -d --build --remove-orphans
+                "$SCRIPT_DIR/compose.sh" restart reverse-proxy ;;
+  proxy-reload) "$SCRIPT_DIR/compose.sh" restart reverse-proxy ;;
+  down)         "$SCRIPT_DIR/compose.sh" down ;;
+  logs)         "$SCRIPT_DIR/compose.sh" logs -f ;;
+  reset)        "$SCRIPT_DIR/reset-lab.sh" ;;
+  reset-hard)   "$SCRIPT_DIR/reset-lab.sh" --hard ;;
+  reset-origin) "$SCRIPT_DIR/reset-lab.sh" --hard-origin ;;
+  -h|--help|"") usage ;;
+  *) echo "[error] unbekannte Aktion: $1"; usage; exit 2 ;;
+esac

scripts/workshop.ps1

@@ -18,17 +18,7 @@ if (-not $repoWslPath) {
   exit 1
 }
 
-switch ($Action) {
+$linuxCommand = "./scripts/lab.sh $Action"
-  "bootstrap"    { $linuxCommand = "./scripts/bootstrap.sh" }
-  "up"           { $linuxCommand = "./scripts/compose.sh up -d --build" }
-  "redeploy"     { $linuxCommand = "./scripts/compose.sh up -d --build --remove-orphans && ./scripts/compose.sh restart reverse-proxy" }
-  "proxy-reload" { $linuxCommand = "./scripts/compose.sh restart reverse-proxy" }
-  "down"         { $linuxCommand = "./scripts/compose.sh down" }
-  "logs"         { $linuxCommand = "./scripts/compose.sh logs -f" }
-  "reset"        { $linuxCommand = "./scripts/reset-lab.sh" }
-  "reset-hard"   { $linuxCommand = "./scripts/reset-lab.sh --hard" }
-  "reset-origin" { $linuxCommand = "./scripts/reset-lab.sh --hard-origin" }
-}
 
 $wslArgs = @()
 if ($Distro) {