docs(concepts): ACME and EST travel in the config with write-only secrets

declarative-config said the acme and est blocks never crossed the API.
They do now, with their secrets returned blank and kept on apply, and a
switch waits for a reboot in a maintenance window. ca-roles adds that a
Root refuses both blocks.

Depends on CryptOS-PKI/cryptos-node#286.

Signed-off-by: Bugs5382 <12115015+Bugs5382@users.noreply.github.com>

Author: Bugs5382

docs/concepts/ca-roles.md

@@ -116,6 +116,10 @@ A subordinate issues leaf certificates from leaf profiles (`is_ca: false`) in it
 
 SCEP and WSTEP are not available.
 
+:::caution[A Root serves no enrolment protocol]
+ACME and EST run on an intermediate or issuing node only. A Root's config with `pki.acme` or `pki.est` is refused by `config apply`, the maintenance-mode install and the first-boot ceremony, so a Root never opens either endpoint.
+:::
+
 ## Key algorithms
 
 `pki.root_key_alg` sets the node's own CA key: `ECDSA-P384`, `RSA-3072` or `RSA-4096`. Despite the name, it applies to every role. The CA key also decides the signature algorithm on everything the node signs, so a platform that only accepts RSA signatures needs an RSA key at every level of its chain.

docs/concepts/declarative-config.md

@@ -119,7 +119,7 @@ Most of the config is read once, at boot. Two fields are read live, every time t
 - `pki.profiles`, the certificate profiles;
 - `pki.root_leaf_issuance`.
 
-A change limited to those two takes effect straight away and reports `requires_reboot=false`. Anything else (network, role, revocation settings, the management link, and so on) is saved but only takes effect on the next boot, and reports `requires_reboot=true`. The node never switches those at runtime.
+A change limited to those two takes effect straight away and reports `requires_reboot=false`. Anything else (network, role, revocation settings, the management link, switching ACME or EST on or off, and so on) is saved but only takes effect on the next boot, and reports `requires_reboot=true`. The node never switches those at runtime, and `cryptosctl status` shows `Reboot: pending` until the reboot.
 
 :::warning[A reboot takes the CA offline]
 Restart the node with an orderly shutdown, not a hypervisor hard reset:
@@ -141,10 +141,12 @@ With `pki.allow_unverified_revocation_url: true`, the node issues certificates w
 
 `config apply` also prints a warning, without stopping, when a profile's `validity_days` runs past the node's own CA certificate. Certificates from that profile will be cut short to the CA's `notAfter`.
 
-## Parts the API does not carry
+## Secrets in the config
 
-:::caution[The acme and est blocks do not travel over the API]
-`pki.acme` and `pki.est` hold secrets (account binding keys and enrolment passwords) and are not part of the API's config message. `config get` leaves them out, and `config apply` keeps whatever blocks the node already has. You cannot turn ACME or EST on, off or change them through `config apply` today.
+`pki.acme` and `pki.est` hold secrets: account binding keys and enrolment password digests. They travel in the API's config message, but only one way. `config get` returns them blank, next to their `key_id` or `username`, and a `config apply` that leaves one blank keeps the value the node stores for that identifier. A new identifier needs its value. So the read, edit, apply cycle above works for these blocks too, without the secrets ever coming back out of the node.
+
+:::warning[Switching ACME or EST waits for a reboot]
+Adding a protocol's block switches it on and removing it switches it off, but only at the next boot. Plan the reboot for a maintenance window: the node stops issuing while it restarts.
 :::
 
 ## The Fleet Manager uses the same file