Enrollment

How a device gains a transport identity the gateway will trust. A per-device enrollment certificate is issued by the SOC Backend, and the agent proves possession over mTLS. Identity is bound to the key, not the hostname.

Sequence

Identity derivation

endpoint_id = SHA-256(SubjectPublicKeyInfo_DER)[..8] — the first 8 bytes of the SHA-256 of the full SPKI DER, as 16 lowercase hex chars. Both sides compute it the same way: the agent from its own keypair (enrollment/fingerprint.rs), the gateway from the presented mTLS leaf cert (identity/mtls_trust.rs). The gateway enforces verify_fingerprint(claimed_id, spki) and rejects a mismatch, then applies a revocation-list gate. The SOC backend independently records the enrollment after an integrity check on the same id.

Credential lifecycle

The SOC backend’s one-click issuance (POST /api/v1/bootstrap/enrollment/issue) signs a per-device ECDSA P-256 leaf in process against an enrollment CA whose key is age-encrypted at rest; the CA itself is created offline. The device receives this as its durable X5C enrollment credential; the private key is stored in the DPAPI-protected keystore (enrollment/keystore.rs). The agent then uses the X5C credential to obtain and renew its short-lived operational mTLS cert from step-ca, and enrollment/certmanager.rs hot-swaps renewals without tearing down the Control Channel or the telemetry link.

In dev, the gateway can instead trust the SPKI self-reported in Hello.public_key when ALLOW_INSECURE_HELLO_TRUST=true — never in production.