HTTPS mit Caddy

Ohne etwas davor ist die Oberfläche im Klartext auf Port 3100 erreichbar. Für den ersten Start ist das in Ordnung, für den Betrieb nicht: Über die Verbindung laufen Anmeldedaten, Rechnungen und Kundendaten. Es geht auch gar nicht ohne – das Erneuerungs-Token der Anmeldung ist im Betrieb ein Secure-Cookie, und das legt der Browser über Klartext nicht ab. Die Anmeldung hielte keine Viertelstunde.

Davor kommt Caddy, derselbe wie bei WorkTime Pro. Er holt und erneuert das Zertifikat von Let's Encrypt selbst.

1. Der Name muss auf den Server zeigen

Beim DNS-Anbieter einen A-Eintrag (und AAAA, falls der Server IPv6 hat) anlegen, dann prüfen:

dig +short buero.ihrbetrieb.de

Vorher lohnt es nicht, Caddy zu starten: Let's Encrypt prüft über genau diesen Namen.

2. Nur die nötigen Ports öffnen

sudo ufw allow 22/tcp && sudo ufw allow 80/tcp && sudo ufw allow 443/tcp && sudo ufw enable

Port 3100 (und 3000 von WorkTime Pro) bleiben zu.

3. Die Oberfläche nur an die Loopback-Adresse binden

In die .env:

WEB_BIND=127.0.0.1
APP_URL=https://buero.ihrbetrieb.de

Dann docker compose -p workoffice -f docker-compose.selfhost.yml up -d. Unter PORTS muss danach 127.0.0.1:3100->3100/tcp stehen, nicht 0.0.0.0:3100->3100/tcp. APP_URL ist die Adresse, unter der die Leute die Oberfläche aufrufen – sie steht in Links aus Mails, und nur von dieser Herkunft aus darf ein Browser die API ansprechen (mehrere Adressen gehen kommagetrennt; die erste gilt für die Links).

4. Caddy einrichten

Läuft WorkTime Pro schon, ist Caddy installiert. Dann den Block aus deploy/Caddyfile unter den von WorkTime in /etc/caddy/Caddyfile hängen:

sed -e 's/buero\.ihrbetrieb\.de/IHR-NAME.example.de/' deploy/Caddyfile \
  | sudo tee -a /etc/caddy/Caddyfile > /dev/null
sudo caddy validate --config /etc/caddy/Caddyfile \
  && sudo chown -R caddy:caddy /var/log/caddy && sudo systemctl reload caddy

Läuft noch nichts, Caddy aus dessen Paketquelle installieren, deploy/Caddyfile nach /etc/caddy/Caddyfile kopieren, den Namen ersetzen und genauso prüfen und starten.

Zwei Handgriffe sind dabei kein Beiwerk:

• caddy validate vor dem Neuladen. Ein Tippfehler brächte sonst auch WorkTime Pro zu Fall, das am selben Caddy hängt.
• chown danach. validate läuft als root und legt dabei schon die Protokolldatei /var/log/caddy/workoffice.log an. Gehört sie root, startet der Dienst (Benutzer caddy) mit „permission denied“ nicht.

Was im Block steht

• Ein einziges Ziel: reverse_proxy 127.0.0.1:3100. Die Oberfläche liefert auch die API aus. Eine eigene Regel für /api wäre nicht nur überflüssig, sie könnte die Anmeldung brechen – das Cookie mit SameSite=Strict ginge an eine zweite Herkunft gar nicht erst mit.
• Uploads bis 210 MB. Die Datenübernahme aus Lexware Office nimmt Exporte bis 200 MB an; Belege sind auf 15 MB begrenzt.
• HSTS für ein Jahr: Der Browser merkt sich, dass es die Seite nur über HTTPS gibt.
• Zugriffsprotokoll sieben Tage – es enthält IP-Adressen, also personenbezogene Daten.

X-Forwarded-For, -Proto und -Host setzt Caddy von selbst. Die API wertet sie aus, etwa für die Taktsperre und für die Adresse im Protokoll einer Angebotsannahme.

5. Nachsehen

curl -I https://buero.ihrbetrieb.de/
curl -s https://buero.ihrbetrieb.de/api/ready
curl -I --connect-timeout 3 http://<server-ip>:3100/

Die erste Zeile muss 200 mit gültigem Zertifikat liefern, die zweite "mandantentrennung":"greift", die dritte muss von außen scheitern.

Homepage und Programm unter zwei Namen

So läuft WorkOffice Pro beim Hersteller: workoffice-pro.de zeigt die Homepage, www. leitet dorthin, app.workoffice-pro.de ist das Programm. Beides liefert dieselbe Oberfläche aus; getrennt wird nur in Caddy. Anmelden, Registrieren, Passwort, Einladung und Kundenportal leitet Caddy von der Homepage auf app. – die Sitzung liegt so nie auf der Homepage, und APP_URL zeigt auf app.. Die Vorlage dafür ist deploy/Caddyfile.homepage-und-app; nötig sind A-Einträge für @, www und app. An der Anwendung ändert sich dafür nichts.

Wenn es nicht geht