v0,28,2

docs/RENEWAL.md

@@ -79,7 +79,7 @@ migration of its stored paths. A system-wide timer should not also manage these
 RustProxy-isolated profiles.
 
 For a certificate intentionally owned by a separate system Certbot instead of this managed
-renewal subsystem, 0.28.1 can reference the Certbot lineage directly. Configure a manual
+renewal subsystem, 0.28.2 can reference the Certbot lineage directly. Configure a manual
 certificate id with both absolute paths, for example
 `/etc/letsencrypt/live/example.com/fullchain.pem` and
 `/etc/letsencrypt/live/example.com/privkey.pem`. RustProxy resolves the `live/` symlinks again on
@@ -94,10 +94,36 @@ curl --fail --show-error -X POST \
   https://proxy-admin.example/api/certificates/shared-cert/reload
 ```
 
-The service identity must be able to traverse the Certbot directories and read the files. External
-private keys may be owner-only (`0600`) or group-readable (`0640`) for a restricted group; they
-must not be executable, group-writable or world-accessible. The referenced files are not copied
-into RustProxy backups.
+The service identity must be able to traverse the Certbot directories and read the files. RustProxy
+0.28.2 accepts named POSIX ACL read access and does not require an exact `0600`/`0640` mode.
+External certificate/key files must not be group/world-writable, and private keys must not be
+world-readable. Parent directories must be root- or RustProxy-owned and not group/world-writable
+(apart from root-owned sticky ancestors such as `/tmp`). The referenced files are not copied into
+RustProxy backups.
+
+For a normal Certbot lineage, grant traversal without directory listing and read only the archive
+files. A default ACL is useful, but a renewer may create a new private key with mode `0600` and
+mask inherited ACL permissions. The reliable hook therefore reapplies the named read ACL to the
+newly resolved generation before calling the reload API:
+
+```bash
+setfacl -m u:rustproxy:--x /etc/letsencrypt/ /etc/letsencrypt/live/ /etc/letsencrypt/archive/
+setfacl -m u:rustproxy:--x /etc/letsencrypt/live/example.com/ /etc/letsencrypt/archive/example.com/
+setfacl -m u:rustproxy:r-- /etc/letsencrypt/archive/example.com/fullchain*.pem \
+  /etc/letsencrypt/archive/example.com/privkey*.pem
+setfacl -m d:u:rustproxy:r-- /etc/letsencrypt/archive/example.com/
+
+# Run these two resolved-file grants after renewal, before the 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)"
+```
+
+For external material below `/etc/ssl`, traversal of the protected root can be granted separately:
+
+```bash
+setfacl -m u:rustproxy:--x /etc/ssl/
+```
 
 If direct read access to the Certbot tree is undesirable, use the copy/deploy workflow instead: