Add an HTTPS listener for the web dashboard — prerequisite for OIDC, and the shared token currently crosses the LAN in the clear #2562

Erik's call, 2026-08-23: yes, the product gets an HTTPS listener. This is the prerequisite #2550 (OIDC) is blocked on, and it is worth having on its own.

Where things stand

grep -c UseHttps across Darling/ returns 0. DarlingWebHostService calls options.Listen(...) with no TLS configuration at all, so the dashboard is plain HTTP in every mode.

Two consequences:

1. OIDC cannot work in network mode. Most identity providers refuse a non-HTTPS redirect_uri, with the near-universal exception of http://localhost — which is the loopback case, the one mode that does not need OIDC. Network mode, which does, is the mode that cannot have it.
2. The shared bearer token crosses the network in the clear, and per OIDC sign-in for the web dashboard: give the web surface a per-user identity instead of one shared token #2550 that token gates the dashboard's write paths (custom-view CRUD, alert tuning). The token→cookie exchange is well built — constant-time compare, HMAC-signed HttpOnly SameSite=Strict cookie, CIDR allowlist, Host-header anti-rebind — but all of it rides on an unencrypted transport once the listener is not on loopback.

That second point stands independently of OIDC. Even if #2550 never happens, a LAN-exposed dashboard behind a bearer token deserves TLS.

Decisions I will take unless told otherwise

• Opt-in, not default-on. A loopback-only dashboard has no use for TLS and forcing a certificate on it would break the zero-config local case, which is the common one.
• Operator-supplied certificate first. A PFX or PEM pair referenced from web.network, resolved through the existing file:/env: secret indirection (Darling on Linux: Docker/compose distribution of the service + TimescaleDB store #1804) rather than a new mechanism. Most people exposing this on a LAN have a cert, and an internal CA is the normal answer.
• A self-signed fallback is a maybe, not a default. It buys encryption without authentication and trains people to click through warnings. If it ships it should be explicit and loud, not silent.
• Config lives in web.network alongside listen/allowFrom/token, and is therefore file-only and restart-only, matching what that block already logs about itself.
• HTTP does not silently keep working when TLS is configured. Either redirect or refuse — decided during implementation, but not "both quietly listening".

What needs care

• Kestrel binds both loopback and the primary address today (DarlingHostBinding's ladder). TLS must not change which addresses are bound or the CIDR gate's behaviour — those are separately reasoned and pinned in DarlingWebAuthTests.
• The Host-header allowlist (anti-DNS-rebind) is always on and must stay on.
• Certificate loading has to fail closed. The existing precedent is right there: an undecryptable web token refuses to expose and binds loopback-only rather than exposing tokenless. An unreadable or expired certificate should behave the same way — never silently downgrade to HTTP.
• Expiry is an operational trap. A certificate that expires takes the dashboard down. At minimum, log the expiry at startup and warn when it is close.
• The container path (Darling/compose/) mounts secrets already; a certificate is one more of those, and darling.sample.json should show it.

Not in scope

Certificate issuance or ACME. The product should consume a certificate, not manage a PKI.

Related: #2550 (OIDC, blocked on this), #1804 (the file:/env: secret indirection to reuse), #1562 / #1649 (the current browser auth model this must not disturb).