Device identity
A device holds two credentials, and they do different jobs.
The enrollment credential proves the device is allowed to join. It ships with the firmware, either as a token you generated for that one device or as a claim key shared by a production batch. It can do nothing except enroll.
The operational identity is what the device uses every day: a private key it generated itself, the certificate Connhex signed for it, and the broker credentials that came back with it. That one certificate covers everything the device does afterwards: the broker, its configuration, and pulling firmware.
They stay separate so that a factory credential can be rotated or revoked without touching devices already in the field, and so a device can renew its certificate on its own for the rest of its life.
How enrollment works
- The device generates an ECC P-256 key pair.
- It builds a certificate signing request, which carries only the public key.
- It sends the request to Connhex along with its enrollment credential.
- Connhex signs it and returns the certificate with the rest of the device's configuration.
The private key never leaves the device, so Connhex never holds it and your production line never handles it.
When the profile asks for approval, step 4 puts the device in the queue instead. It keeps asking every 30 seconds and collects its identity as soon as you admit it.
What your devices need to reach
| Host | Port | For |
|---|---|---|
edge.<your-domain> | 443 | Enrollment, certificate renewal, configuration, firmware |
edge.<your-domain> | 8883 | MQTT |
On Connhex SaaS that is edge.connhex.com. Outbound HTTPS and MQTTS are all a device needs: nothing has to be forwarded in, and devices behind NAT or on cellular links work without any network configuration.
Certificate lifetime
Certificates last 30 days. Once two thirds of that has passed, the device generates a new key pair and asks for a new certificate, using the one it already holds as proof of who it is. No human, factory step or enrollment credential is involved. See Certificate lifecycle for what happens when a device misses that window.
A device needs roughly correct time for certificates to validate at all. Run NTP, or fit an RTC.
Where credentials live on the device
Connhex Edge uses /data/connhex/, and it is the layout to follow if you write your own enrollment for an agent-less image. Put it somewhere your updates do not replace. Files are 0600, owned by root.
| File | Holds |
|---|---|
identity.json | device id, broker credentials, channels, CA chain |
device.key | the operational private key, replaced at every renewal |
client.crt | the current certificate |
ca.pem | your instance's CA chain |
This directory has to sit outside the root filesystem slots. If it does not, every image update wipes the device's identity and the device comes back as a new one.
The store owns the identity, and any software on the device adopts what it finds there. That is what lets you add or remove Connhex Edge from an image without the device losing who it is.
When the device cannot hold its own key
Connhex-managed keys. Connhex creates the key pair and delivers it with the configuration, which is how devices that don't support certificate enrollment (hardware too constrained to generate a key) can connect securely.