# MDM Setup — Phasen

## Revisions-Log

| Datum       | Was geändert                                                                                   |
|-------------|-----------------------------------------------------------------------------------------------|
| 2026-05-10  | Initial: Phasen A–G mit Factory-Reset-Approach für Phase F                                    |
| 2026-05-24  | Phase F pivotiert auf Backup-Sandwich (TechLockdown-Stil); Scope erweitert um DNS-/VPN-Lock   |
| 2026-05-24-late | DEV-Test zeigt: VPN-Restrictions blocken Rebreak-eigene NEVPNManager-Calls. Scope korrigiert: VPN-Restrictions raus, DNS bleibt als Fallback-Layer. Saubere MDM-VPN-Lösung als Phase F.2 |

## Phase A ✅ Server-Bootstrap

Erledigt vor 2026-05-10.

- apt-update + apt-upgrade
- Pakete installiert: nginx, postgresql, docker.io, certbot, python3-certbot-nginx, ufw, fail2ban
- UFW konfiguriert: 22/tcp, 80/tcp, 443/tcp erlaubt, default-deny
- fail2ban aktiv (SSH-Brute-Force-Schutz)
- DNS: IONOS A-Record `mdm.rebreak.org` → 178.105.101.137

## Phase B ✅ TLS-Zertifikat

Erledigt vor 2026-05-10.

- `certbot --nginx -d mdm.rebreak.org` ausgeführt
- Cert liegt in `/etc/letsencrypt/live/mdm.rebreak.org/`
- certbot.timer (systemd) erneuert automatisch

## Phase C ✅ NanoMDM Container + nginx-Vhost

Erledigt 2026-05-10.

**Was gemacht wurde:**

1. PostgreSQL-Datenbank `nanomdm` mit User `nanomdm` und Passwort aus `/root/.nanomdm_db_pass` angelegt
2. `ALTER USER nanomdm WITH PASSWORD '...'` explizit gesetzt (scram-sha-256 braucht explizites Passwort)
3. `pg_hba.conf` ergänzt für Docker-Netze (172.17.0.0/16, 172.18.0.0/16)
4. `listen_addresses` in `postgresql.conf` auf `localhost,172.17.0.1,172.18.0.1` erweitert
5. MDM CA generiert: `ca.key` + `ca.crt` in `/opt/nanomdm/certs/`
6. `/opt/nanomdm/.env` mit `NANOMDM_DB_PASS` geschrieben (chmod 600)
7. `/opt/nanomdm/docker-compose.yml` mit `network_mode: host` (kritisch, sonst postgres nicht erreichbar wegen NAT-Masquerade)
8. `docker compose up -d` — Container läuft, `starting server listen=127.0.0.1:9000` bestätigt
9. nginx-Vhost `/etc/nginx/sites-available/mdm.rebreak.org` geschrieben + in sites-enabled symlinkt
10. `nginx -t && systemctl reload nginx`
11. Externer Verify: `curl -sI https://mdm.rebreak.org/` → `HTTP/2 404` von nanomdm (korrekt, kein 502)

**Bekannte Tücken aus diesem Setup:**

- `micromdm/nanomdm` auf Docker Hub existiert nicht. Korrektes Image: `ghcr.io/micromdm/nanomdm:latest`
- nanomdm v0.9 kennt `-storage postgres` nicht. Korrekt: `-storage pgsql` (bzw. `NANOMDM_STORAGE=pgsql`)
- Docker-Compose-Netzwerk (172.18.x) geht via NAT durch Host — Postgres sieht externe IP als Source. Lösung: `network_mode: host` im Compose, dann verbindet nanomdm direkt zu `127.0.0.1:5432`
- nginx 1.24 kennt `http2 on;` nicht (das ist nginx 1.25+). Korrekt: `listen 443 ssl http2;`

## Phase D ✅ Apple Push CSR generiert

Erledigt 2026-05-10.

```
openssl req -newkey rsa:2048 -nodes \
  -keyout /opt/nanomdm/certs/push.key \
  -out /opt/nanomdm/certs/push.csr \
  -subj '/CN=ReBreak MDM Push/O=Raynis/C=DE'
chmod 600 /opt/nanomdm/certs/push.key
```

CSR-Content liegt in `/opt/nanomdm/certs/push.csr`. Der private Key `push.key` verlässt den Server nie.

## Phase D.0.5 ✅ mdmcert.download Signing-Request

Erledigt 2026-05-10.

**Warum dieser Schritt notwendig ist:**

Apple Push Notification Service (APNS) für MDM akzeptiert keine rohen CSRs von Self-Hostern direkt im Apple Push Portal. Apple verlangt, dass die CSR von einem akkreditierten MDM-Vendor signiert wird. Self-Hoster ohne Apple-MDM-Vendor-Status nutzen `mdmcert.download` — ein Service des MicroMDM-Teams, der die CSR mit einem akzeptierten Vendor-Key gegen-signiert und encrypted per Email zurückschickt.

**Was passiert:**
1. Wir schicken unseren CSR base64-encoded + eine Encryption-Cert an `https://mdmcert.download/api/v1/signrequest`
2. mdmcert.download signiert ihn mit ihrem Apple-akkreditierten Vendor-Key
3. Sie verschlüsseln das Ergebnis mit unserer Encryption-Cert (PKCS7) und senden es per Email an `hello@chahine-brini.com`
4. Das entschlüsselte Ergebnis (nicht der raw CSR, nicht das `.b64.p7`) wird im Apple Push Portal hochgeladen

**Was gemacht wurde:**

1. Encryption-Keypair auf dem MDM-Server generiert:
   - Cert: `/opt/nanomdm/certs/mdmcert-encryption.crt` (public, wird an mdmcert.download geschickt)
   - Key: `/opt/nanomdm/certs/mdmcert-encryption.key` (chmod 600, verlässt Server nie)

   ```bash
   openssl req -new -newkey rsa:2048 -nodes \
     -keyout /opt/nanomdm/certs/mdmcert-encryption.key \
     -x509 -days 365 \
     -out /opt/nanomdm/certs/mdmcert-encryption.crt \
     -subj '/CN=ReBreak mdmcert encryption'
   chmod 600 /opt/nanomdm/certs/mdmcert-encryption.key
   ```

2. Signing-Request an mdmcert.download abgeschickt (shared public API-Key aus micromdm-Source, öffentlich dokumentiert):

   ```bash
   PUSH_CSR_B64=$(base64 -w0 /opt/nanomdm/certs/push.csr)
   ENC_CRT_B64=$(base64 -w0 /opt/nanomdm/certs/mdmcert-encryption.crt)

   curl -X POST https://mdmcert.download/api/v1/signrequest \
     -H "Content-Type: application/json" \
     -H "User-Agent: micromdm/certhelper" \
     -d "{\"csr\":\"$PUSH_CSR_B64\",\"email\":\"hello@chahine-brini.com\",\"key\":\"<shared-api-key>\",\"encrypt\":\"$ENC_CRT_B64\"}"
   ```

   Antwort: `{"result":"success"}`

**Naechster Schritt:** Email von mdmcert.download bei `hello@chahine-brini.com` prüfen. Anhang-Name hat Format `mdm_signed_request.YYYYMMDD_HHMMSS_NNN.plist.b64.p7`. Dann weiter mit Phase D.0.7.

**Technische Details (wichtig fuer Decrypt):**
- Der Dateiname endet auf `.b64.p7` — irreführend. Der tatsächliche Inhalt ist **hex-encoded PKCS7**, nicht base64. (Quelle: micromdm/micromdm cmd/mdmctl/mdmcert.download.go, Decrypt-Pfad)
- Der Decrypt-Befehl (`openssl cms` oder PKCS7-Tooling) muss zuerst hex→binary decodieren, dann PKCS7 mit dem mdmcert-encryption.key entschlüsseln

## Phase D.0.7 ⏳ Signed CSR entschlüsseln

**Voraussetzung:** Email von mdmcert.download mit Anhang empfangen (Phase D.0.5 abgeschlossen)

**Wer:** Chahine schickt den Anhang per `scp` auf den MDM-Server. Oder Backyard entschlüsselt wenn Anhang auf den Server kopiert wurde.

**Schritte:**

1. Anhang von Email speichern (z.B. `mdm_signed_request.20260510_XXXXXX.plist.b64.p7`)

2. Datei auf Server kopieren:
   ```bash
   scp ~/Downloads/mdm_signed_request.*.plist.b64.p7 rebreak-mdm:/opt/nanomdm/certs/signed_request.p7
   ```

3. Hex→Binary dekodieren + PKCS7 entschlüsseln (micromdm-Tooling macht beides intern):
   ```bash
   # Hex-String aus der Datei zu Binary konvertieren
   xxd -r -p /opt/nanomdm/certs/signed_request.p7 > /opt/nanomdm/certs/signed_request.der

   # PKCS7 mit unserem Encryption-Key entschlüsseln
   openssl cms -decrypt \
     -in /opt/nanomdm/certs/signed_request.der \
     -inform DER \
     -inkey /opt/nanomdm/certs/mdmcert-encryption.key \
     -recip /opt/nanomdm/certs/mdmcert-encryption.crt \
     -out /opt/nanomdm/certs/push_request.plist
   ```

4. Ergebnis `/opt/nanomdm/certs/push_request.plist` prüfen — sollte eine Apple Plist-Datei sein.
   ```bash
   head -5 /opt/nanomdm/certs/push_request.plist
   # Erwartete Ausgabe: <?xml version="1.0" ... oder PEM-ähnliches Format
   ```

5. DIESE Datei (`push_request.plist`) wird bei https://identity.apple.com hochgeladen (Phase D.1).

**Status:** Wartet auf Email-Empfang bei `hello@chahine-brini.com`

## Phase D.1 ⏳ Apple Push Cert — Benutzeraktion

**Voraussetzung:** Phase D.0.7 abgeschlossen (entschlüsseltes Plist `push_request.plist` auf Server)

**Wer:** Chahine (muss mit Apple-ID eingeloggt sein, die als MDM-Zertifikats-Owner gelten soll)

**WICHTIG: NICHT den raw push.csr oder die `.b64.p7`-Datei hochladen.**
Hochgeladen wird die entschlüsselte `push_request.plist` aus Phase D.0.7.

**Schritte:**

1. Phase D.0.7 abschliessen — `push_request.plist` auf Server entschlüsselt
2. Datei lokal runterladen: `scp rebreak-mdm:/opt/nanomdm/certs/push_request.plist ~/Downloads/`
3. Oeffne https://identity.apple.com/pushcert/ im Browser (einloggen mit Apple-ID)
4. Klicke "Create a Certificate"
5. Lade `push_request.plist` hoch (NICHT push.csr, NICHT die `.b64.p7`-Datei)
6. Download das ausgestellte Zertifikat (`.pem` oder `.cer`)
7. Kopiere es auf den Server: `scp ~/Downloads/MDMCertificate.pem rebreak-mdm:/opt/nanomdm/certs/push.pem`
7. Setze Permissions: `ssh rebreak-mdm "chmod 600 /opt/nanomdm/certs/push.pem"`
8. Informiere Backyard-Agent fuer Phase E

**Wichtig:**
- Das Zertifikat ist an die Apple-ID geknuepft, mit der es erstellt wurde
- Gueltigkeitsdauer: 1 Jahr
- Bei Renewal: GLEICHEN `push.key` verwenden (kein neues keypair generieren)
- Wenn push.key verloren geht: alle Geraete muessen re-enrollen

## Phase D.2 ✅ NanoMDM mit Push-Cert konfiguriert

Erledigt 2026-05-10.

**Was gemacht wurde:**

1. NanoMDM API-Key generiert (32-char-hex), in `/opt/nanomdm/.env` (`NANOMDM_API=`) + `/root/.nanomdm_admin_pass` (chmod 600)
2. Container force-recreated mit neuem env-file
3. Postgres-Schema von https://raw.githubusercontent.com/micromdm/nanomdm/main/storage/pgsql/schema.sql geladen + applied (8 tables: devices, push_certs, commands, etc.) — fehlte aus initial-setup
4. Push-Cert via `PUT /v1/pushcert` (basic-auth) hochgeladen → in `push_certs` table
5. Verify: Topic `com.apple.mgmt.External.816a2d4a-4ce1-4b44-9264-2831b891206a`, valid bis 2027-05-10
6. External smoke-test: `curl -u nanomdm:<key> https://mdm.rebreak.org/version` → `{"version":"v0.9.0"}` ✅

**Bekannte Tücke:** Initial-setup hat das postgres-schema nicht angewendet. NanoMDM-Container hat keine eingebaute migrate-step. Schema muss manuell via `psql -f schema.sql` geladen werden bevor erster API-call funktioniert.

## Phase E ⏸ Email-Distribution an Ina — geparkt (User-Decision 2026-05-10)

**Status: PARKED — alles server-side ready, Versand verschoben.**

User-Entscheidung: PIN-Versand an Ina jetzt nicht — wird später nachgeholt. iPhone-Enrollment kann ohne laufen (MASTER-PIN ist Recovery-Backup, nicht Voraussetzung für enrollment).

Server-Status:
- ✅ MASTER-Recovery-PIN auf Server: `/root/.nanomdm_master_pin` (chmod 600)
- ✅ Ina-Email-Draft auf Server: `/root/INA_EMAIL_DRAFT.md` (chmod 600)
- ✅ Resend-API-Key auf Server: `/root/.resend_api_key` (chmod 600)
- ⏸ Resend-Domain-Verify ungetan — Versand würde fehlschlagen ohne `chahine-brini.com` oder `rebreak.org` verified

Reaktivierung: User sagt „Phase E GO", wir verifizieren Domain in Resend, senden, fertig. Files bleiben bis dahin auf Server.

## Phase F ⏳ Device-Enrollment via Backup-Sandwich

**Revidiert 2026-05-24** — alter Plan (Factory-Reset + Apple Configurator) war User-Friction-Killer. Niemand reset sich freiwillig sein iPhone. Neuer Plan: Backup-Sandwich-Approach wie TechLockdown / iMazing Configurator Edition.

Phase F ist NICHT mehr auf Phase E blockiert (Ina-Email-Distribution kann nachgeholt werden).

### Mechanismus

```
1. Backup (idevicebackup2 encrypted)  →  vollständig auf Mac
2. Supervise (cfgutil prepare)         →  wiped Gerät, Supervised-Flag wird gesetzt
3. Restore (idevicebackup2 restore)    →  Daten zurück, Supervised-Flag bleibt persistent
4. Enroll  (mobileconfig install)      →  via QR-Code aus Rebreak-App, OTA über mdm.rebreak.org
```

Find-My-Disable ist Voraussetzung für Step 2 (Activation Lock blockt sonst den Wipe). Apple-ID-Passwort des Users wird live abgefragt — nicht automatisierbar.

### Komponenten dieser Phase

- `ops/mdm/bootstrap-tool/` — Bash-Scripts orchestrieren Backup → Supervise → Restore auf User-Mac (Mac-only Phase 1; Windows = Phase 2 via iMazing-Lizenz oder libimobiledevice-Erweiterung)
- `ops/mdm/profiles/rebreak-iphone-protection.mobileconfig` — Profil-Template mit den unten genannten Restrictions
- `backend/server/api/mdm/enroll.get.ts` — User-spezifisches signed Profil ausliefern, plus QR-Code-Endpoint
- `apps/rebreak-native/lib/mdm.ts` + `app/(protection)/mdm-setup.tsx` — Lyra-geführter Onboarding-Flow in der App

### Scope (erweitert 2026-05-24, revidiert 2026-05-24-late nach DEV-Test)

Profil enthält:

| Restriction                                  | Wirkung                                                      |
|----------------------------------------------|--------------------------------------------------------------|
| `allowAppRemoval = false`                    | Rebreak (und alle anderen Apps) nicht löschbar via Long-Press — zeigt nur "Vom Home-Screen entfernen", App bleibt in Mediathek (verifiziert auf TechLockdown-supervisem iPhone 2026-05-24) |
| `PayloadRemovalDisallowed = true`            | Profil nicht via Settings → Allgemein → VPN/Geräteverwaltung entfernbar |
| `allowEraseContentAndSettings = false`       | User kann iPhone nicht via Settings → Reset wipen           |
| `allowUIConfigurationProfileInstallation = false` | User kann keine konkurrierenden Profile installieren    |
| DNS-Settings-Payload (DoH)                   | System-DNS auf `dns.rebreak.org/dns-query` gelocked — always-on Fallback-Schicht |

**VPN-Restrictions bewusst RAUS** (Test-Befund 2026-05-24):
`allowVPNCreation=false` blockt auch Rebreak-eigene `NEVPNManager`-Aufrufe ("Permission denied"). Apple unterscheidet im API-Call nicht zwischen User und App. Konsequenz:
- App-VPN (Rebreak NEPacketTunnel) bleibt App-managed + user-toggleable — wie heute
- MDM-DNS-Payload ist always-on Fallback: auch wenn User Rebreak-VPN ausschaltet, DNS-Filter greift weiterhin
- Bypass-Vektor: User installiert 3rd-Party-VPN (z.B. ExpressVPN). Akzeptiert für Prototype — 5-min-Friktion, trifft planenden Rückfall nicht impulsiven
- Saubere Lösung wäre **Phase F.2**: MDM-pushed-VPN mit `ProviderBundleIdentifier=org.rebreak.app.PacketTunnelExtension`, dann braucht App-Code kein eigenes `NEVPNManager.saveToPreferences` mehr → echtes "VPN nur via MDM"

Bewusste Trade-offs:
- `allowAppRemoval=false` ist GLOBAL — kein per-Bundle-ID-Lock möglich ohne MDM-managed-Convert (zusätzlicher InstallApplication-Command, Phase F.5 später). Für Prototype akzeptiert: User der sich self-bindet darf auch andere Support-Apps nicht löschen — Feature, kein Bug.
- Determinierter User kann via zweitem Mac unsupervisen (ABM-ADE wäre der einzige echte Hard-Lock, ist aber strukturell nicht erreichbar für Consumer-iPhones). Akzeptabel für DiGA-Sucht-Kontext: wir hoben Friktion, nicht Festung.

Bewusst NICHT im Scope:
- KEIN App-Store-Block (Casino-Apps gibt's eh nicht im iOS-App-Store)
- KEINE Web-Content-Filter-Payload (Browser-Casinos werden vom Rebreak-NEFilter geblockt)
- KEINE Restriktionen die nicht direkt mit Casino-Bypass-Prevention zu tun haben

### Hardware-/Tool-Voraussetzungen

- Mac mit macOS (User-Mac, NICHT Server-Mac) — für cfgutil + libimobiledevice
- USB-Kabel iPhone↔Mac
- Apple Configurator 2 (kostenlos, Mac App Store) — für `cfgutil` CLI
- libimobiledevice via `brew install libimobiledevice` — für `idevicebackup2`
- Supervision-Identity einmalig generiert via cfgutil (persistent, gleicher Mac reused)
- iPhone mit deaktiviertem Find-My (live während Setup)

### Akzeptanz-Test (M2)

Auf einem physischen Test-iPhone nach kompletter Sandwich-Sequenz:
- [ ] `Settings → Allgemein → Info` zeigt "Dieses iPhone wird verwaltet/beaufsichtigt"
- [ ] Long-Press auf Rebreak-Icon → kein "App löschen" mehr
- [ ] `Settings → VPN → Rebreak` → Toggle disabled / nicht entfernbar
- [ ] `Settings → Allgemein → VPN, DNS und Gerätemanagement` → Profil zeigt "Nicht entfernbar"
- [ ] Daten/Apps/Login-States/iMessage-History intakt nach Sandwich
- [ ] Rebreak-App erkennt MDM-Enrollment-Status via Backend-Check und unlockt Pro/Legend-Schutz-UI

## Phase G ⏳ iPad-Enrollment (optional, später)

Identisch zu Phase F, gleicher flow:
1. iPad via USB-C mit Mac verbinden
2. Apple Configurator 2 → Supervised-Mode → factory-reset
3. MDM-enrollment-profile von `https://mdm.rebreak.org/enroll`
4. ReBreak-iOS app installieren (läuft nativ auf iPad)
5. Verifyieren: ReBreak nicht entfernbar, MDM-profile nicht entfernbar

**Aufwand:** ~30min nach Phase F. Apple Push Cert deckt iPad mit ab (kein zusätzlicher cert nötig).

**Voraussetzung:** Phase F erfolgreich getestet auf iPhone.

## Phase H ⏳ MacBook-Enrollment (optional, später)

Anders als iPhone/iPad weil:
- **Kein ReBreak-Mac-app** existiert → MDM-profile muss eigene Blocking-Mechanik mitbringen
- Lösung: **Web-Content-Filter-Payload** im profile (DNS/URL-blocklist auf OS-Ebene)
- Mac-Supervised-Mode: factory-reset des MacBook nötig (analog iPad), via Apple Configurator 2 + USB-C

**Schritte:**

1. ReBreak-Blocklist (~208k domains) als Web-Content-Filter-Payload formattieren
   - Payload-type: `com.apple.webcontent-filter`
   - oder `com.apple.dnsSettings.managed` für DNS-level-block
2. MDM-profile assemblen mit:
   - `allowMDMProfileRemoval=false` (braucht supervised-mode)
   - Web-Content-Filter mit Casino-Blocklist
   - Optional: `allowSafariAutoFill=false` (verhindert auto-login auf bekannten casino-sites)
3. MacBook factory-reset → Apple Configurator 2 → supervised-mode → MDM-enrollment
4. Verify: Casino-domain im Browser → blocked

**Aufwand:** ~1 Tag (blocklist-conversion + profile-assembly + test). Plus factory-reset-zeit.

**Voraussetzung:**
- Phase F+G erfolgreich
- User explizites GO (factory-reset MacBook = großer Schritt)
- Backup von wichtigen MacBook-Daten

**Tradeoff:** Kein ReBreak-Mac-app = nur URL-blocking, keine SOS-features, kein Lyra, keine Community auf Mac. Wer ReBreak-features auf Mac will, braucht später entweder native Mac-app (s. `ops/mac-version-research.md`) oder Browser-Extension.