Running behind a reverse proxy

The recommended setup: the application speaks plain HTTP and the proxy terminates TLS — IIS, nginx or Caddy. The HTTPS page in the installer then stays empty, and the certificate sits where it is renewed anyway.

Three things belong with it

1 · Set the public address. PublicBaseUrl to the address users actually call — for instance https://rechnung.firma.de. It appears in the links in email.

Without this, sign-in links behind a proxy lead nowhere

The application then derives the address from the respective request and logs a warning. Behind a proxy this is the most common cause of sign-in links that do not work.

2 · Register the proxy’s address. KnownProxies to the address of the proxy. Only from there are X-Forwarded-For and X-Forwarded-Proto accepted.

Without this entry, all clients share one rate-limit window

The application then discards the headers, and both rate limiting and the log see only the proxy’s address. This is easy to overlook because nothing breaks — until rate limiting hits everyone at once.

Loopback is trusted in any case; a proxy on the same host needs no entry.

3 · Check health over HTTP. /health against the HTTP port and localhost, not through the proxy — otherwise a fresh certificate becomes monitoring’s first stumbling block.

What the application sets itself

• Strict-Transport-Security (effective over HTTPS only)
• X-Content-Type-Options: nosniff
• Referrer-Policy: strict-origin-when-cross-origin
• Cache-Control: no-store on HTML result pages — because they contain invoice data

What the application does not do

No automatic redirect from HTTP to HTTPS

There is no “HTTPS only” option in the installer either. Anyone needing both arranges it at the proxy. See also Security boundaries.

An example configuration

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

The options in detail are under Options: mail and network.