v0,28,2

docs/INSTALL.md

@@ -1,4 +1,4 @@
-# Installing and updating RustProxy 0.28.1
+# Installing and updating RustProxy 0.28.2
 
 The scripts prepare a Linux/systemd installation. This source archive is **not a
 verified production build**: Rust/Cargo, real CA operations, live systemd startup
@@ -201,7 +201,7 @@ The provider script is embedded in the RustProxy binary; this command is diagnos
 If another service already owns a certificate through the system Certbot, keep that lineage
 outside RustProxy's managed ACME profiles and create/use a **manual** RustProxy certificate id.
 
-The preferred 0.28.1 workflow is to select **Existing server files / external paths** and then
+The preferred 0.28.2 workflow is to select **Existing server files / external paths** and then
 **External files (absolute paths)** in the Certificates panel. For example:
 
 ```text
@@ -223,9 +223,44 @@ curl --fail --show-error -X POST \
 ```
 
 The `rustproxy` service identity must be able to traverse the parent directories and read both
-files. An external private key may be `0600` when owned by that identity or `0640` with a
-restricted group readable by RustProxy; world access, group write and executable bits are
-rejected. These external files are not included in a RustProxy backup.
+files. RustProxy 0.28.2 supports POSIX ACLs and does not require one exact chmod value. External
+certificate/key files must not be group/world-writable, and an external private key must not be
+world-readable. Named ACL read access for `rustproxy` is accepted; the operating system still
+performs the final access check when RustProxy opens the file. Every parent directory in the
+configured and resolved path must be owned by root or the RustProxy service user and must not be
+group/world-writable (root-owned sticky ancestors such as `/tmp` are the narrow exception).
+These external files are not included in a RustProxy backup.
+
+The packaged systemd service keeps `/etc/letsencrypt` and `/etc/ssl` read-only. `ReadOnlyPaths=`
+does **not** grant Unix permissions, so use narrow ACLs instead of making private keys globally
+readable. For example:
+
+```bash
+# Traversal only for the protected roots.
+setfacl -m u:rustproxy:--x /etc/ssl/
+setfacl -m u:rustproxy:--x /etc/letsencrypt/ /etc/letsencrypt/live/ /etc/letsencrypt/archive/
+
+# Traversal only for this Certbot lineage.
+setfacl -m u:rustproxy:--x /etc/letsencrypt/live/example.com/ /etc/letsencrypt/archive/example.com/
+
+# Read only the certificate/key material RustProxy actually needs.
+setfacl -m u:rustproxy:r-- /etc/letsencrypt/archive/example.com/fullchain*.pem \
+  /etc/letsencrypt/archive/example.com/privkey*.pem
+
+# Optional default ACL for renewers that preserve inherited ACL masks.
+setfacl -m d:u:rustproxy:r-- /etc/letsencrypt/archive/example.com/
+
+# Robust renewal-hook form: re-grant read access to the current generation before API reload.
+setfacl -m u:rustproxy:r-- \
+  "$(readlink -f /etc/letsencrypt/live/example.com/fullchain.pem)" \
+  "$(readlink -f /etc/letsencrypt/live/example.com/privkey.pem)"
+```
+
+Because `/etc/letsencrypt/live/.../*.pem` are symlinks into `archive/`, access must cover the
+resolved archive files. Some renewal tools recreate private keys as `0600` and may mask an
+inherited default ACL; therefore the renewal wrapper should reapply the named file ACL before
+calling the RustProxy reload API. Never grant `w` to `rustproxy` on the Certbot tree. Verify a deployment
+with `sudo -u rustproxy test -r /etc/letsencrypt/live/example.com/privkey.pem && echo OK`.
 
 If you do not want the RustProxy service to read `/etc/letsencrypt`, keep the previous copy/deploy
 workflow instead. A Certbot deploy hook can publish every successful renewal into RustProxy's