PKI (Device Certificate Management)
Overview
ALP-CONNEX includes a built-in Public Key Infrastructure (PKI) that gives every Fleet device its own cryptographic identity. Instead of a shared password or a static API key, each edge device authenticates to the Management Platform with a unique private key and a certificate issued by the platform itself. All device-to-platform traffic after onboarding uses mutual TLS (mTLS): the device proves who it is with its certificate, and the platform proves who it is with its own — neither side has to trust the connection based on network location alone.
The PKI module is tightly integrated with Fleet Management (see the Fleet Management page): registering a device automatically prepares everything needed for it to receive its first certificate, and certificate renewals for already-enrolled devices are delivered through the same remote-command channel used for restarts, updates, and configuration pushes.
Key Concepts
Certificate Authorities (CAs)
The platform operates its own internal Certificate Authority hierarchy:
- A root CA sits at the top of the hierarchy. Additional intermediate (issuing) CAs can be created underneath it, and underneath those, forming a tree.
- Exactly one CA is marked as the default at any time — this is the CA used to sign newly issued device certificates. Administrators can change which CA is the default.
- Each CA has its own validity period, chosen when it is created.
- A CA can be revoked. Revoking a CA invalidates every certificate ever issued under it, so this is normally reserved for decommissioning an entire trust branch.
By default, every new device certificate is issued by the platform-wide default CA. A Device Group in Fleet Management can optionally be pinned to a different, specific CA — every device placed in that group then has its certificates issued from that CA instead. This is useful when different sites, customers, or environments need certificates that trace back to separate, isolated CAs rather than a single shared one. See Additional Services / Fleet Management → Device Groups.
Certificates
Every certificate the platform issues — for a device or for a CA — carries a subject name, a serial number, a validity window, and a status:
| Status | Meaning |
|---|---|
| Active | Currently valid and usable |
| Expiring | Still valid, but nearing the end of its validity window |
| Expired | Past its validity window |
| Revoked | Explicitly invalidated before expiry |
Device certificates are additionally scoped to a purpose (client authentication vs. server authentication) and are always linked back to the device they were issued for.
Enrollment Tokens
An enrollment token is a one-time, device-bound, time-limited credential used only to bootstrap the very first certificate for a device (or to bootstrap a replacement one, see Reissue below). It is not a long-term credential: once it has been used successfully, it cannot be used again, and it automatically expires if it is never used.
Onboarding a Fleet Device
This is the end-to-end flow that gives a new edge device its own certificate, from registration to its first authenticated connection.
- Register the device. An operator registers the device in Fleet Management with a name and a site, exactly as described in the Fleet Management documentation.
- Enrollment token issued automatically. Registration immediately requests a fresh enrollment token for that specific device from the PKI module — this happens automatically, no separate step is needed. The token is short-lived (on the order of minutes) and is bundled together with the device's identifier into a ready-to-use install command.
- Install the agent. The operator copies the install command and runs it on the target device. This sets up the device agent with the Management Platform's address and the enrollment token; at this point the device does not yet have a certificate.
- Local key generation. When the agent starts for the first time, it generates its own private key locally, on the device — the private key is never transmitted anywhere — together with a matching certificate request that identifies the device.
- Enrollment request. The agent sends this certificate request to the platform's enrollment endpoint, presenting the enrollment token as proof that the device was legitimately registered by an operator.
- Verification and issuance. The platform checks that the token is valid, unused, and matches the device, then consumes it (so it cannot be replayed) and signs the certificate request using the current default CA. The issued certificate, together with the certificate chain needed to validate it, is returned to the device.
- Certificate stored, mTLS active. The agent stores its private key and certificate locally. From this point on, every request the device makes to the Management Platform is authenticated with mutual TLS using this certificate — the enrollment token is no longer used or needed.
- Idempotent restarts. If the agent restarts later, it detects that it already holds a valid certificate and skips enrollment entirely, continuing to use its existing identity.
Ongoing Certificate Lifecycle
Automatic renewal
The agent continuously watches the remaining validity of its own certificate. A configurable amount of time before it would expire, the agent requests a new certificate on its own initiative — this time authenticating with its current, still-valid certificate instead of an enrollment token, so no operator action is required.
The switch to the new certificate is carried out in a crash-safe way: if the device loses power or restarts in the middle of a renewal, it recovers to a single, consistent set of credentials the next time it starts, rather than being left with a mismatched key and certificate.
Operator-triggered renewal
An operator can also trigger a renewal manually from the Certificate Management area for any certificate that is still active or approaching expiry. Doing so does not renew the certificate immediately on the server — instead, it queues a renewal request that is delivered to the device the same way other fleet commands are (see Fleet Management → Remote Commands), and the device carries out the actual renewal itself the next time it checks in.
Renewal requests go through a visible lifecycle — queued, dispatched to the device, and then completed, failed, cancelled, or expired — so operators can track exactly what happened. A request that hasn't been picked up by the device yet can be cancelled.
Reissue
If a device's certificate has already expired, it can no longer prove its identity well enough to request an automatic renewal. In that situation, an operator can reissue the certificate: this generates a brand-new enrollment token for that device, which is then used to bootstrap the device again, following the same steps as the initial onboarding (steps 4–7 above).
Revocation
An operator can revoke a device's certificate (or an entire CA) at any time — for example when a device is decommissioned, replaced, or suspected of being compromised — by providing a reason. A revoked certificate is rejected immediately for any further authentication attempt.
Certificate Management (Web UI)
The Management UI provides a dedicated Certificate Management area (separate from the Fleet Management page) with three views:
| View | Purpose |
|---|---|
| Certificates | All issued device certificates, their remaining validity, and status. Supports downloading a certificate, triggering a renewal, reissuing an expired certificate, or revoking it. |
| Certificate Authorities | The CA hierarchy, browsable as a table or as a tree. Supports creating a new CA (as a root or under an existing parent), marking a CA as the default, downloading a CA's certificate or its certificate revocation list (CRL), and revoking a CA. |
| Certificate Requests | A queue of pending, completed, and failed certificate operations (currently renewals) dispatched to devices, including which certificate and device each request concerns, timestamps, and any error message. |
Clicking a certificate opens a detail view showing its full trust chain — from the device certificate up through any intermediate CAs to the root — which can be used to navigate directly to the issuing CA or back to the linked device.
Troubleshooting
Device stuck without a certificate
- Confirm the enrollment token used during installation has not expired — tokens are short-lived and single-use. If it has expired or was already consumed, reissue a new one for the device from Certificate Management or by registering the device again.
- Check that the device can reach the Management Platform's enrollment endpoint over the network.
Device suddenly cannot connect after working before
- Check whether the device's certificate has expired or was revoked in Certificate Management.
- If expired, use Reissue to generate a new enrollment token and re-run onboarding on the device.
Renewal request stuck as "Queued"
- The device only picks up a queued renewal on its next check-in — confirm the device is online and sending heartbeats (see Fleet Management).
- A queued request that is no longer needed can be cancelled from the Certificate Requests view.