feature: Caddy serves the status page and the Router Manager over HTTPS with a certificate from Let's Encrypt.

ADR.md

@@ -49,8 +49,9 @@ port on both interfaces in UFW, so the choice of `web.listen` is made by the ser
 writes the features and the facts it resolves to `/run/vpn-router/web.json`.
 
 Consequences: By default the service is reachable from the internet on the external address;
-`web.listen` set to `internal` keeps it to the internal network. It serves plain HTTP, so the
-passwords of `/auth` and the tokens cross the internet unencrypted. A change of `web.listen`
+`web.listen` set to `internal` keeps it to the internal network. It serves plain HTTP itself;
+HTTPS is Caddy's (ADR-21), so on the plain HTTP port the passwords of `/auth` and the tokens
+cross the internet unencrypted. A change of `web.listen`
 needs no run of setup, since the firewall does not depend on it; the package's upgrade runs
 setup, which writes the rules. `/` and `/status` have no authentication, which is acceptable because they are
 read only and show no configuration. It runs as root, because `swanctl` and `wg` need it, with `NoNewPrivileges`,
@@ -486,3 +487,33 @@ Consequences: slapd's `otp` overlay accepts each code once, so a change right af
 needs the next code. Changing the password revokes the user's refresh tokens, so the user's
 Manager session ends with its access token. An enrolled user who has lost the authenticator
 needs an administrator.
+
+## ADR-21: Caddy from the Ubuntu archive serves HTTPS with a certificate from Let's Encrypt
+
+Status: Accepted
+
+Context: The status web service and the Router Manager are reachable from the internet (ADR-2),
+and `/auth` and the Manager's sign-in carry passwords. Both are small servers on the standard
+library's `http.server`, which would need certificates, their renewal and a TLS setup of their
+own. Browsers trust a public CA, not the router's.
+
+Decision: Caddy, the `caddy` package of the Ubuntu archive, is the HTTPS proxy. While
+`https.enabled` is `true` (the default) and `wan.local_fqdn` is set, `vpn-router-setup` writes
+`/etc/caddy/vpn-router.Caddyfile`: a site for `wan.local_fqdn` on `https.web_port` (7444) for the
+web service and, while the Router Manager is installed, one on `https.manager_port` (7443) for
+the manager, each passing calls to the service on `127.0.0.1`. Caddy obtains and renews the
+certificate from Let's Encrypt with the HTTP challenge on port 80, which the firewall opens on
+the external interface; `auto_https disable_redirects` keeps port 80 to the challenge. The
+package's drop-in for `caddy.service` points it at that file and keeps it from starting before
+the file exists, so `/etc/caddy/Caddyfile`, a configuration file of the `caddy` package, is left
+unchanged. Both services always listen on `127.0.0.1` as well as on the interfaces their
+`listen` settings name, and trust `X-Forwarded-For` from it, which Caddy sets from the peer and
+never takes from the client.
+
+Consequences: HTTPS needs `wan.local_fqdn` in public DNS pointing at the router and port 80
+reachable from the internet; until then Caddy retries and the HTTPS ports do not answer. The
+certificate and the ACME account are in `/var/lib/caddy`. Plain HTTP stays as the `listen`
+settings set it, so `internal` keeps passwords off the internet. Caddy's admin endpoint listens
+on `localhost:2019`, which `caddy reload` uses. Port 80 and the HTTPS ports are not available
+to Docker containers while HTTPS is on. The Manager's HTTPS port is a setting of the router, not
+of the manager.