certbot: certs/ links into /etc/letsencrypt, mounted at the same path; the backup follows them

C-A1, C-Q4, D-guide:258, :291, :722. certbot's live/<host>/*.pem are
relative links into ../../archive/<host>/ (eff-certbot docs, "Where are
my certificates?": point a server at them "or create symlinks"). The
guide had `ln -s /etc/letsencrypt/live/<host> certs` and the nginx
fragment mounted live/<host> alone: inside the container the links led
into a directory it did not have - postfix-config.sh's [ -f ] false, no
copy, Postfix without a certificate - and the panel's backup, reading
certs/ through /selfpost-deploy, skipped links silently.

Now certs/fullchain.pem and certs/privkey.pem are links to
/etc/letsencrypt/live/<host>/, and /etc/letsencrypt is mounted read-only
at the same path: a commented line in deploy/docker-compose.yml for the
Apache scenario, mounted in the nginx fragment (./nginx/certbot-etc). The
guide's steps add certbot's own commands for a server that is not root -
chmod 0755 live archive, chgrp 998 + chmod 0640 the key, which certbot
keeps on renewal - so the panel reads them (Health, backup). Postfix's
side follows links already ([ -f ], cp, cmp, openssl). The vhost comment
says the same. The backup table: links are followed by the panel's
backup; a stopped tar stores them as links unless -h (GNU tar).

internal/backup: addTree follows, for certs/ only, a link to a regular
file and archives that file under the link's name; a link to nothing
reachable is an error naming it and the mount.

Tests: TestCertsLinksAreFollowed (certs/ -> live/ -> archive/, the
archive holds the files; the tree gone, Check names the dangling link;
Linux). Stand (2026-10-15, make e2e, exit 0): the stand mounts
./letsencrypt at /etc/letsencrypt; new certbot_layout_followed puts a new
pair into letsencrypt/archive/, relative links in live/, absolute links
in certs/, recreates the container: 465 serves the new serial, Health
names no renewal waiting, and the full backup holds certs/*.pem as
regular files with the archive's bytes. go vet and go test ./... pass on
the server (24 packages); the Linux-only tests of this session run there
and pass.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/audit-2026-10-12.md

@@ -1005,12 +1005,16 @@ those after it move up one patch number each.
    it; a test with two concurrent opens behind a held lock. - **Opus**
    *Done 2026-10-15:* the test fails without the fix exactly as the
    register said ("table settings already exists") and passes with it.
-- [ ] **Certificates from certbot** (C-A1, C-Q4, D-guide:258, :291, :722):
+- [x] **Certificates from certbot** (C-A1, C-Q4, D-guide:258, :291, :722):
    certbot's `live/` files are relative links into `archive/`, so mounting
    `live/<host>` alone, or linking `certs` to it, leaves Postfix without a
    certificate and the backup without it. The deploy fragments mount
    `/etc/letsencrypt` read-only and point the paths into it; the backup
    follows a link under `certs/` to a regular file. - **Opus**
+   *Done 2026-10-15:* `certs/` holds links into `/etc/letsencrypt/live/`,
+   mounted read-only at the same path; certbot's own `chmod 0755` and
+   `chgrp`/`chmod 0640` for a server that is not root (kept on renewal) let the
+   panel read them; no copying hook.
 - [ ] **The rest of what the sources contradict** (C-M7 `<pct>0</pct>`,
    C-E2 the e2e zone serial, C-D1 a release gate comparing the image's
    package versions with the ones cited, C-K8/K9 and the comments the

docs/guide.md

@@ -255,14 +255,14 @@ SelfPost isn't tied to a specific proxy; pick whichever fits your host:
 
 | Proxy | Where certs live | Fragment |
 |---|---|---|
-| **Apache** (default/recommended) | Host disk, via the certbot Apache plugin — PEM files ready to bind-mount, no extraction step. | [deploy/apache/selfpost-vhost.conf](../deploy/apache/selfpost-vhost.conf) |
-| nginx | Host disk, via a certbot sidecar container — same PEM-ready shape as Apache. | [deploy/nginx/](../deploy/nginx/) |
+| **Apache** (default/recommended) | Host disk, via the certbot Apache plugin — `certs/` links to them, no extraction step. | [deploy/apache/selfpost-vhost.conf](../deploy/apache/selfpost-vhost.conf) |
+| nginx | Host disk, via a certbot sidecar container — the same shape as Apache. | [deploy/nginx/](../deploy/nginx/) |
 | Caddy | Automatic ACME, zero extra containers — simplest, but its on-disk cert path is versioned internal layout, not a stable API; verify it for the Caddy version you run. | [deploy/caddy/](../deploy/caddy/) |
 | Traefik | Bundled inside `acme.json` — needs a small extraction script to produce standalone PEM files. | [deploy/traefik/](../deploy/traefik/) |
 
 Apache is the recommended default because the certbot Apache plugin already
-writes plain `fullchain.pem`/`privkey.pem` files to a predictable path with no
-extra moving parts between "certificate issued" and "Postfix can read it."
+keeps `fullchain.pem`/`privkey.pem` at a predictable path with no extra moving
+parts between "certificate issued" and "Postfix can read it."
 
 **The proxy needs no security configuration of its own.** The panel emits its
 own `Content-Security-Policy`, `Strict-Transport-Security`, `X-Frame-Options`,
@@ -276,7 +276,8 @@ reject every form submission as cross-origin — the log says so explicitly,
 printing the `Origin` and `Host` it compared.
 
 In every case the proxy terminates HTTPS for the panel; the resulting
-certificate must end up under `./certs` as `fullchain.pem` and `privkey.pem`.
+certificate must end up under `./certs` as `fullchain.pem` and `privkey.pem` —
+the files, or links that lead to them inside the container.
 
 **Apache (recommended, on the host).** Install Apache with `ssl`, `proxy`, and
 `proxy_http` enabled. Copy
@@ -288,10 +289,30 @@ then issue a certificate:
 sudo certbot --apache -d mail.example.com
 ```
 
-Point `./certs` at the PEM files certbot wrote (symlink is fine):
+Link the two files into `./certs` and let the container see what the links
+lead to. certbot's `live/` files are themselves relative links into
+`archive/` (certbot's documentation, "Where are my certificates?", advises
+pointing servers at them or linking to them), so the whole of
+`/etc/letsencrypt` is mounted, read-only and at the same path — uncomment that
+line in `docker-compose.yml`. Mounting `live/mail.example.com` alone, or
+linking `certs` to it, gives the container links into a directory it does not
+have: Postfix then starts without a certificate.
 
 ```sh
-ln -s /etc/letsencrypt/live/mail.example.com certs
+mkdir certs
+ln -s /etc/letsencrypt/live/mail.example.com/fullchain.pem certs/fullchain.pem
+ln -s /etc/letsencrypt/live/mail.example.com/privkey.pem certs/privkey.pem
+```
+
+The panel reads them as its own user (Health shows the certificate, a full
+backup carries both files), through the container's group 998. certbot's
+documentation gives the way for a server that is not root, and certbot keeps
+the key's group and mode at every renewal:
+
+```sh
+sudo chmod 0755 /etc/letsencrypt/live /etc/letsencrypt/archive
+sudo chgrp 998 /etc/letsencrypt/archive/mail.example.com/privkey*.pem
+sudo chmod 0640 /etc/letsencrypt/archive/mail.example.com/privkey*.pem
 ```
 
 **nginx (containerised).** From the `deploy/` directory, merge the nginx
@@ -306,8 +327,20 @@ docker compose -f docker-compose.yml -f nginx/docker-compose.nginx.yml up -d
 ```
 
 Edit [deploy/nginx/nginx.conf.example](../deploy/nginx/nginx.conf.example) and
-replace `mail.example.com` first. The fragment bind-mounts certbot's output into
-both nginx and SelfPost.
+replace `mail.example.com` first. The fragment mounts certbot's directory into
+both nginx and SelfPost, at `/etc/letsencrypt`; `./certs` holds two links to
+`/etc/letsencrypt/live/mail.example.com/` — a path that exists inside the
+container, not on the host — and the panel reads the key through group 998,
+as in the Apache case:
+
+```sh
+mkdir certs
+ln -s /etc/letsencrypt/live/mail.example.com/fullchain.pem certs/fullchain.pem
+ln -s /etc/letsencrypt/live/mail.example.com/privkey.pem certs/privkey.pem
+sudo chmod 0755 nginx/certbot-etc/live nginx/certbot-etc/archive
+sudo chgrp 998 nginx/certbot-etc/archive/mail.example.com/privkey*.pem
+sudo chmod 0640 nginx/certbot-etc/archive/mail.example.com/privkey*.pem
+```
 
 **Caddy (containerised, automatic ACME).** Edit
 [deploy/caddy/Caddyfile](../deploy/caddy/Caddyfile) and the `<hostname>` placeholders
@@ -654,10 +687,13 @@ both the panel and Postfix —
 chgrp 998 certs/privkey.pem && chmod 640 certs/privkey.pem
 ```
 
-— and have whatever renews the certificate do the same (a certbot deploy hook,
-for one). A key readable by root alone is enough for Postfix, but then the
-panel refuses to make a backup and names the file: it does not hand over an
-archive without the key.
+— and have whatever renews the certificate do the same; certbot does it by
+itself, keeping the group and mode of a key on renewal (with `certs/` as links
+into `/etc/letsencrypt`, the commands of "Reverse proxy" above give certbot's
+own files the group). A key readable by root alone is enough for Postfix, but
+then the panel refuses to make a backup and names the file: it does not hand
+over an archive without the key. Links under `certs/` are followed: the
+archive holds the files they lead to.
 
 **2. `selfpost-backup` CLI — while the container is running (no downtime).**
 The panel button and this command call the same code path: a consistent SQLite
@@ -719,7 +755,7 @@ methods avoid it by stopping first.
 | SQLite consistency | `VACUUM INTO` snapshot | Safe when stopped | Safe when stopped |
 | `data/log/` | Excluded | Included (optional exclude) | Included (optional exclude) |
 | Postfix queue | No | Yes | Yes |
-| `certs/` private key | Yes (the panel needs it readable by group 998) | Yes | No — deploy files separate |
+| `certs/` private key | Yes (the panel needs it readable by group 998; links are followed) | Yes when `certs/` holds the files; links are stored as links unless `tar -h` | No — deploy files separate |
 | `data/manifest.json` | Written (version stamp) | Absent | Absent |
 | Restore version check | Yes — must match image tag | No | No |
 | Post-restore *Resync* | Yes, on first boot | No | No |

docs/roadmap.md

@@ -42,7 +42,7 @@ in `git log` and [CHANGELOG.md](../CHANGELOG.md).
 | from-header-binding | Hold a message's `From:` header against the application that sends it | shipped `2.4.0` | 9/9 | [plans/from-header-binding.md](plans/from-header-binding.md) |
 | panel-redesign | Panel redesign (accepted mockups, design contract) | shipped `2.0.0` | 27/27 | [plans/panel-redesign.md](plans/panel-redesign.md) |
 | schema-squash | Squash SQLite migrations into a 2.x baseline | built in panel-redesign (stage 1) | — | [plans/panel-redesign.md](plans/panel-redesign.md) |
-| audit-2026-10-12 | Follow-ups of the 2026-10-12 full-tree code audit, seven stages | in progress (stage 0 shipped `2.4.2`, stages 1+2 `2.5.0`, 2b `2.5.1`; next stage 2c → `2.5.2`) | 43/81 | [audit-2026-10-12.md](audit-2026-10-12.md) |
+| audit-2026-10-12 | Follow-ups of the 2026-10-12 full-tree code audit, seven stages | in progress (stage 0 shipped `2.4.2`, stages 1+2 `2.5.0`, 2b `2.5.1`; next stage 2c → `2.5.2`) | 44/81 | [audit-2026-10-12.md](audit-2026-10-12.md) |
 
 **Recommended order** (not binding; owner, 2026-10-09: feature order follows
 development convenience): **panel-redesign** shipped as `2.0.0` (2026-10-11) and