v0.28.1

docs/RENEWAL.md

@@ -79,7 +79,27 @@ 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, use a manual certificate id and a Certbot deploy hook that runs, for example:
+renewal subsystem, 0.28.1 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
+every targeted reload, so a renewal wrapper only needs to call:
+
+```bash
+curl --fail --show-error -X POST \
+  -H 'Authorization: Bearer TOKEN' \
+  -H 'X-RustProxy-Certificate-Key: certbot-main' \
+  -H 'Content-Type: application/json' \
+  --data '{}' \
+  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.
+
+If direct read access to the Certbot tree is undesirable, use the copy/deploy workflow instead:
 
 ```bash
 /opt/rustproxy/current/rust-proxy --data-dir /var/lib/rustproxy tls deploy --id shared-cert \
@@ -87,9 +107,10 @@ renewal subsystem, use a manual certificate id and a Certbot deploy hook that ru
   --key /etc/letsencrypt/live/example/privkey.pem
 ```
 
-The command resolves Certbot's `live/` symlinks locally, validates and stages a new pair, then
-publishes the existing id through the normal revisioned configuration path. Do not point this
-workflow at a certificate carrying RustProxy `issuer` metadata; one lineage must have one owner.
+That command resolves the Certbot `live/` symlinks locally, validates and stages a managed pair,
+then publishes the existing id. Do not use deploy for an id configured with external absolute
+paths, and do not point either external-manual workflow at a certificate carrying RustProxy
+`issuer` metadata; one lineage must have one owner.
 
 Staging certificates are not trusted by browsers. A Dry run checks renewal
 validation but does not deploy the staging result. Only an explicit production