docs(swarm): what the uncovered-service-name warning means
Names the two ways out (install the sub-CA, or pin back under the hive domain) and says why it is a warning rather than an assertion — the module can see what it issues, not what the operator installed.
This commit is contained in:
parent
155df39ee4
commit
44164d1a89
1 changed files with 21 additions and 0 deletions
|
|
@ -37,6 +37,27 @@ Moving the swarm CA onto its own host is then a matter of moving
|
|||
`services.hyperhive.swarm.ca.stateDir` and leaving `autoConfigure` off —
|
||||
there is no second code path to switch to.
|
||||
|
||||
### The warning about uncovered service names
|
||||
|
||||
The swarm's service names (`swarm.forge.domain`,
|
||||
`swarm.matrix.gatewayHost`, `swarm.authelia.domain`) default to
|
||||
siblings of the hive domain — `forge.<swarm.domain>`, not
|
||||
`forge.<hive domain>`. The hive CA's leaf is a **single-label** wildcard
|
||||
over the hive's own domain, so it cannot cover them; only the
|
||||
swarm-services leaf can, and this host signs that one only under
|
||||
`autoConfigure`. A hive with neither serves the hive leaf on those names
|
||||
and every client sees a name mismatch.
|
||||
|
||||
So `hive-tls` emits an eval-time **warning** naming the uncovered names.
|
||||
It is deliberately not an assertion: this module can see what *it* is
|
||||
able to issue, but not an operator-installed sub-CA in
|
||||
`swarm.ca.stateDir`, an external ACME setup, or a certificate delivered
|
||||
by any other means. If you have arranged one, the warning is expected
|
||||
and can be ignored. Otherwise either install the sub-CA, or pin the
|
||||
names back under the hive domain — a supported migration, since the
|
||||
sub-CA is constrained to the *configured* names and the swarm root
|
||||
carries no name constraints at all.
|
||||
|
||||
## Constraints on the material
|
||||
|
||||
The root's private key never reaches the nix store: the store is
|
||||
|
|
|
|||
Loading…
Reference in a new issue