Skip to main content

Device certificate enrollment

Introduction​

Strongbox issues and manages certificates for the Avassa platform itself and for the applications you deploy. But at many edge sites there is a third population that also needs certificates: the equipment around the platform. Industrial controllers, sensors, gateways, cameras, meters and similar devices increasingly authenticate with X.509 certificates rather than passwords or pre-shared keys.

This page explains how such devices obtain certificates from Avassa without an operator visiting each one, and what design constraints enrollment protocols bring with them. It is background reading; the practical steps are in Enroll devices with SCEP.

Why device enrollment is its own problem​

Issuing a certificate to a device you administer is easy. Issuing certificates to thousands of devices, spread across remote sites, that you may never physically touch again, is not. Three properties make it hard:

  • Scale and unattended operation. Nobody is going to copy a certificate onto each device by hand, and certainly not again at every renewal. The device has to ask for its own certificate, and keep asking as the certificate ages.
  • Lifetime mismatch. Industrial equipment is commonly in service for fifteen to thirty years. A certificate valid for a year will be renewed many times over the life of the device, so renewal has to be routine rather than a project.
  • Constrained and fixed firmware. Devices often support exactly one enrollment protocol, chosen years ago by their vendor, and it cannot be changed. The platform has to meet the device where it is.

The practical consequence is that a device PKI is judged less by which algorithms it supports than by whether enrollment, renewal, revocation and validation work unattended, at remote sites, over unreliable links.

Enrollment against a tenant CA​

In Avassa, device enrollment is a service offered by a TLS CA that you create inside a tenant. Enabling enrollment on a CA does not change what the CA is: it is still an ordinary Strongbox CA, with the same distribution settings, the same revocation handling and the same automatic renewal and rollover behaviour. Enrollment simply adds a network endpoint through which devices may request certificates from it.

This has a useful consequence. Certificates that devices obtain by enrolling are indistinguishable from certificates issued through the API: they appear under the same CA, they are revoked the same way, they appear in the same CRLs and OCSP responses, and the CA's rollover machinery covers them.

Because CAs are per tenant, different device populations can be given separate trust hierarchies, and a site only holds the CA material for tenants assigned to it.

Enrollment policy​

An enrollment endpoint accepts certificate requests from the network, so what it will agree to sign has to be constrained. Each enrollment-enabled CA carries a policy that governs:

  • Which identities may be requested. A device asks for a specific subject name and subject alternative names; the policy restricts these to a set of permitted domains, optionally including subdomains, and controls whether IP addresses are acceptable.
  • How long issued certificates live. Short lifetimes are preferable when renewal is automatic: they limit the damage from an undetected compromise and they exercise the renewal path often enough that it is known to work.
  • Key strength. Requests carrying keys below the platform's accepted strength are refused.

Every request is also checked for proof of possession: the request must be signed by the private key belonging to the public key being certified, so a device cannot obtain a certificate over a key it does not hold.

SCEP​

SCEP (Simple Certificate Enrollment Protocol, RFC 8894) is the enrollment protocol most widely implemented by existing equipment. It long predates the current generation of standards, and its ubiquity is the reason to support it: for a large amount of installed OT and network equipment, SCEP is the only automated option available.

A device enrolling over SCEP fetches the CA certificate, then submits a PKCS#10 certificate request wrapped in a CMS envelope, authenticated by a challenge password shared with the CA. The platform verifies the envelope, the challenge and the request against the CA's enrollment policy, and returns the issued certificate in a matching envelope.

Two properties of SCEP are worth understanding because they shape how it should be deployed:

  • The challenge password is shared. SCEP authenticates enrollment with one secret configured on the CA, not with a credential unique to each device. Any device that learns it can enroll, subject to the identity policy. This argues for restricting the permitted identities narrowly and for treating the challenge password as a sensitive value.
  • The envelope requires RSA. SCEP encrypts its payloads to the CA using RSA key transport, so a CA that serves SCEP must have an RSA key. This is a property of the protocol rather than of any particular implementation, and it is the reason SCEP cannot be carried forward into a post-quantum world: the key transport it depends on has no post-quantum equivalent within the protocol.

SCEP is therefore best understood as the compatibility path: the way to bring existing equipment into a managed PKI today, while newer protocols carry the long-term story.

EST​

EST (Enrollment over Secure Transport, RFC 7030) is the modern counterpart. It carries the certificate request directly over TLS rather than inside a CMS envelope, which removes SCEP's structural constraints and adds the two properties that matter most for a long-lived fleet.

Renewal against the existing certificate. A device that already holds a certificate from the CA renews by presenting it as its TLS client certificate. No shared secret takes part, so renewal needs neither an operator nor a secret distributed to the fleet. This is what makes short certificate lifetimes practical: if renewal is genuinely automatic, a short lifetime costs nothing and limits exposure.

Per-device bootstrap identity. For its first enrollment a device can authenticate with a client certificate issued by a separate CA that the enrollment CA is configured to trust -- typically a birth certificate installed at manufacture. Each device then authenticates as itself rather than with a fleet-wide secret. A shared secret remains available for devices that have no such credential, but it is the weaker option: one compromised device compromises enrollment for all of them.

Because EST authenticates devices with certificates issued outside this system, it is served on its own network endpoint that accepts client certificates from any issuer. Accepting a certificate at the TLS layer is not the same as trusting it: the certificate is verified against the configured trust CA before any enrollment is honoured, and only the enrollment endpoints are exposed there.

Post-quantum device credentials​

Certificates issued today may still be in service when quantum computers can break classical signatures, and industrial equipment lifetimes make that more than a theoretical concern. The relevant standards are NIST FIPS 204 (ML-DSA) for signatures and FIPS 203 (ML-KEM) for key establishment.

Strongbox can generate a CA with an ML-DSA key, and EST accepts ML-DSA certificate requests, so a device can obtain a credential that is post-quantum in both its own key and the CA's signature over it. SCEP cannot: its envelope depends on RSA key transport, which has no post-quantum equivalent within the protocol. This makes EST the migration path rather than merely the newer option.

In practice the transition is gradual, because device firmware adopts new algorithms slowly. The platform supports running classical and ML-DSA CAs side by side within a tenant, so device populations can move cohort by cohort as their stacks gain support, while the enrollment, renewal and rollover machinery stays the same. Separately, and independently of device certificates, ML-KEM key exchange can be enabled on TLS connections to protect traffic against later decryption.

The wider point is that a post-quantum migration is not an algorithm choice made once. It is an operational capability: enrollment, renewal, revocation and CA rollover that work unattended, at remote sites, often enough that changing a credential is routine.

Where enrollment happens​

Enrollment endpoints are served by the platform alongside the CRL and OCSP endpoints, which means devices can reach a nearby endpoint rather than one central service. This matters at edge sites for the same reason local revocation checking matters: a device should not depend on a WAN link being up in order to obtain or validate a certificate. The addresses to use are published on the CA itself, including address-based forms for networks without DNS.