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.

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.