Deployment identity

Before a client can register against your relay, its machine has to be able to prove which relay it is talking to. That proof is a signed deployment identity you create once, on the operator host.

Create it

rookone-relay deployment init \
  --output-dir /etc/rookone/deployment \
  --deployment-id acme-production \
  --api-url https://relay.acme.example \
  --enrollment-url https://relay.acme.example/api/v1/enrollment

This produces three things: an Ed25519 issuer key, the relay's configuration, and a public deployment-bootstrap.json.

--enrollment-url is optional to the command but not optional in practice. Omit it and the published identity carries a null enrolment endpoint, and every client that tries to register is told the deployment does not support agent enrolment yet. Pass it unless you intend to provision credentials by hand.

Keep the issuer key mounted read-only in the relay container, and point ROOKONE_RELAY_DEPLOYMENT_IDENTITY_FILE at the absolute configuration path.

Hand out the bootstrap — separately

Transfer the public bootstrap file to your client operators through an authenticated channel that is independent of the relay URL.

This is the one rule that carries the whole trust model: a document must never be trusted using a key obtained from that same document. If you email people both the URL and the bootstrap through a channel an attacker controls, you have handed them nothing.

A configured relay publishes a short-lived signed document at /.well-known/rookone-deployment.json with Cache-Control: no-store. That document is what clients fetch; the bootstrap you distributed out of band is what they check it against.

Inspect what you are shipping

rookone-relay deployment export \
  --config /etc/rookone/deployment/deployment-identity.json

rookone-relay deployment inspect \
  --document deployment.json \
  --trust-bundle /secure-transfer/deployment-bootstrap.json

export emits only the signed public document. inspect verifies its schema, lifetime, signature, signer fingerprint, enterprise capability boundary, and endpoints against the separately supplied bootstrap. Neither output contains the private issuer key.

Running inspect against the same two artifacts your users will receive is the cheapest way to find out that you shipped the wrong pair.

What the client does with it

rookone deployment fetch \
  --url https://relay.acme.example \
  --trust /secure-transfer/deployment-bootstrap.json

The client refuses to store a self-hosted deployment without --trust. Hosted deployments are the exception — public certificate authorities authenticate those — and your relay is not one, by design.

Documents are short-lived, so a client's stored context can lapse; the fix on their side is rookone deployment renew, which keeps their agents bound.