Intro
Every device that connects to Connhex needs an identity: a certificate for mutual TLS, credentials for the broker, and the channels it publishes on. Connhex Provisioning issues them.
The device generates its own private key and sends Connhex a request to sign it. The key never leaves the device, so there is no per-device secret for your production line to generate, protect or track.
Two ways in
| You register each device | Devices register themselves | |
|---|---|---|
| How it works | You create the device in Connhex and get a token for it | You put one token in the firmware image, and devices ask to join as they boot |
| Work per device | One token to place | None |
| Suits | Prototypes, small fleets, replacements | Production runs of any size |
| Read | Add a single device | Fleet enrollment |
Both end the same way, with a device holding its own certificate. You can use both across different product lines, and switch a product from one to the other without changing anything on the devices already out there.
What a device ends up holding
- an X.509 certificate signed by your instance's CA, and the private key it generated for it
- broker credentials and the ids of its event and control channels
- its configuration, including the template attached to its model
The certificate is what authenticates everything the device does afterwards, including pulling firmware updates.
Provisioning is your side: creating devices, or setting the rules under which they may join.
Enrollment is the device's side: presenting its credential, sending a signing request, receiving its identity.
Remote init is how devices without a certificate of their own get their configuration. Connhex generates the key material and the device downloads it at every boot. Devices that enroll never use it.
The screenshots in this section come from the Connhex dashboard.