Public key infrastructure

Introduction

Nearly everything in an Avassa system authenticates with X.509 certificates: the platform's own components, the applications you deploy, and increasingly the equipment around them. To make that workable at hundreds of unattended sites, the platform includes a complete PKI -- certificate authorities, issuance, enrollment, distribution, revocation, expiry monitoring and rollover -- operated as part of Strongbox.

This page is the map: what the pieces are, how they relate, and where each one runs. The practical steps live in the how-to guides linked throughout.

Four certificate populations

It helps to distinguish who a certificate is for, because that decides how it is issued and renewed.

The platform itself. Every host and every platform service authenticates with certificates from an internal hierarchy that the platform creates and renews entirely on its own. You never issue or renew these; they are mentioned here because they explain why a site keeps working when its uplink does not -- the trust the platform relies on is local.

Applications. An application that needs a TLS certificate asks for one declaratively: a certificate request is placed in a vault secret, and the application specification references that secret. When a service instance starts, the platform issues a certificate unique to that instance from the tenant CA you name, mounts it into the container, and renews it before expiry. The application never handles enrollment. See SSL/TLS CA.

Devices. Equipment around the platform -- controllers, sensors, gateways, cameras -- cannot be provisioned declaratively, because the platform does not manage it. Instead the device asks for its own certificate through an enrollment protocol served by a tenant CA. This population has its own fundamentals page: Device certificate enrollment.

Publicly trusted certificates. When a service must present a certificate that browsers trust, the platform acts as an ACME client toward an external service such as Let's Encrypt and distributes the result. This is the one population not issued by your own CAs. See ACME certificate provisioning.

Certificate authorities

CAs are created per tenant in Strongbox. A CA is an ordinary piece of tenant configuration: you choose its key type, lifetime and subject, you can build hierarchies with intermediates, and its material is distributed only to the sites its tenant is assigned to.

The default key type is ECDSA. RSA is available where a protocol demands it (SCEP's envelope encryption requires an RSA-keyed CA), and ML-DSA is available where a hierarchy should be post-quantum -- see Post-quantum cryptography. Different CAs in the same tenant can use different algorithms, which is what makes gradual migrations possible.

Everything issued from a CA is equal in its eyes. A certificate obtained by an application through a vault secret, one issued by an operator through the API, and one a device enrolled over SCEP or EST all sit under the same CA, appear in the same CRL, and are covered by the same rollover machinery.

How certificates are issued

Two families of issuance exist, matching the populations above.

Platform-mediated issuance is declarative: a certificate request in a vault secret names a CA and describes the wanted certificate, and the platform issues, delivers and renews -- either directly, or per service instance when an application references the secret. Trust here is the platform's own authorization model -- whoever may write the configuration may request the certificate.

Network enrollment is served to devices over SCEP and EST. Here the requester is an unmanaged device on the network, so each enrollment-enabled CA carries an explicit policy: which names may be requested, whether IP addresses are allowed, how long certificates live, and what credential authenticates a first enrollment (a shared secret or a factory birth certificate). The policy is shared across the protocols, so what a certificate guarantees does not depend on which protocol the device happened to speak.

The choice between them is usually made for you by the device: SCEP for the installed base that supports nothing else, EST for modern devices and for post-quantum credentials.

Validation and revocation

Certificates are checked where they are used. Each CA publishes CRLs, and the platform serves CRL and OCSP endpoints at every site, so a relying party at a site validates against local endpoints rather than a central responder. Revocation is an API operation on the CA, and takes effect in the locally served CRL and OCSP responses. See SSL/TLS CA.

Lifecycle: renewal, expiry, rollover

The design position throughout is that a certificate change must be routine, because at the edge it will happen constantly and unattended.

Renewal. Certificates the platform delivers, it also renews. Enrolled devices renew themselves: EST re-enrollment authenticates with the certificate the device already holds. Short lifetimes are preferable once renewal is automatic -- they limit exposure and exercise the renewal path often enough that it is known to work.

Expiry monitoring. Certificates that leave the platform through channels that do not renew themselves -- a certificate exported to an appliance, for example -- can be tracked with expiry reminders on the issuing CA, raising alerts before they lapse.

CA rollover. A CA certificate itself expires, and replacing one is the most delicate operation in a PKI: every relying party must trust the new certificate before anything it signs reaches them. The platform sequences this as distribute-before-activate -- the next CA certificate is created and distributed ahead of the moment it starts signing, either manually or on configured thresholds. See SSL/TLS CA.

Where the PKI runs

The Control Tower holds the configuration, but issuance and validation run at every site. Each site serves the enrollment endpoints and the CRL and OCSP endpoints for the CAs of its assigned tenants, and each site's endpoints answer with that site's own addresses: read a CA through a site's API and the published enrollment URLs point at the site, not at the Control Tower. Devices should enroll against their local site, so that certificate operations do not depend on a WAN link.

Two ports are involved, for a deliberate reason. The regular API port (4646) serves SCEP alongside the API; it only accepts TLS client certificates from the platform's own hierarchy. EST instead lives on a dedicated enrollment port (4665), because a device's first enrollment is authenticated by a credential from outside the platform -- a factory birth certificate -- which the API listener would reject during the TLS handshake. The enrollment port accepts any client certificate at the TLS layer, defers the trust decision to the enrollment policy, and serves nothing but the enrollment endpoints. If a firewall sits in front of a site or the Control Tower, port 4665 must be open for devices to enroll over EST.

Post-quantum readiness

The PKI is where a future migration to post-quantum algorithms will land: ML-KEM key exchange can be enabled on TLS connections today, and CAs can be created with ML-DSA keys where relying parties support them. The reasoning and the supported scope have a page of their own: Post-quantum cryptography.