Betrieb hinter einem Reverse Proxy

Der empfohlene Aufbau: die Anwendung spricht reines HTTP, TLS terminiert der Proxy — IIS, nginx oder Caddy. Dann bleibt im Installer die HTTPS-Seite leer, und das Zertifikat liegt dort, wo es ohnehin erneuert wird.

Drei Dinge gehören dazu

1 · Die öffentliche Adresse setzen. PublicBaseUrl auf die Adresse, unter der Nutzer die Anwendung aufrufen — etwa https://rechnung.firma.de. Sie steht in den Links der E-Mails.

2 · Die Proxy-Adresse eintragen. KnownProxies auf die Adresse des Proxy. Nur von dort werden X-Forwarded-For und X-Forwarded-Proto übernommen.

Loopback ist ohnehin vertraut; ein Proxy auf demselben Host braucht keinen Eintrag.

3 · Den Zustand über HTTP prüfen. /health gegen den HTTP-Port und localhost, nicht über den Proxy — ein frisches Zertifikat wäre sonst der erste Stolperstein der Überwachung.

Was die Anwendung selbst setzt

Strict-Transport-Security (wirkt nur über HTTPS)
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Cache-Control: no-store auf HTML-Ergebnisseiten — weil darin Rechnungsdaten stehen

Was die Anwendung nicht tut

Beispielhafte Konfiguration

{
  "InvoiceApi": {
    "PublicBaseUrl": "https://rechnung.firma.de",
    "KnownProxies": [ "10.0.0.5" ]
  }
}

Die Optionen im Einzelnen stehen unter Optionen: Mail und Netzwerk.