Skip to main content

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.

Hardware-backed CA keys​

By default a CA's private key is generated by Strongbox and stored, encrypted, in its state. For root CAs with stricter requirements, a CA can instead be configured with a key store: the key pair is created inside an external hardware security module and the private key never exists outside it. Strongbox keeps only a key reference, and every signature the CA makes -- certificate issuance, CRLs -- is performed by the HSM on Strongbox's request. The first supported key store is AWS KMS, whose keys are held in FIPS-validated hardware; a KMS custom key store extends the same configuration to a dedicated CloudHSM cluster.

A key-store CA lives only in the Control Tower. It cannot be distributed to sites, because there is nothing to distribute: sites would receive a reference they have no credentials to use. The intended pattern is a hierarchy: the hardware-backed root issues ordinary intermediate CAs, and those are distributed and do the day-to-day issuance at sites exactly as before. This also keeps the HSM out of every hot path -- it signs intermediates and CRLs, not per-device enrollments.

The split decides where revocation status is answered, which matters for sites that lose contact with the Control Tower: a certificate's status comes from its issuer, so anything a site's intermediate issued is answered by that site, while the intermediate's own status comes from the root and reaches sites as a signed CRL rather than as a signing key.

Delegating signatures also changes what can be audited. The platform records every key store operation in the audit trail of the tenant that owns the CA, naming the key and the operation, while the key store records the same operations against the calling identity. Neither log is authoritative alone: read together, a signature the key store saw and the platform did not is a key used outside the platform. The Control Tower additionally alerts when a key signs more often than the CA is configured to expect, or when the key store starts rejecting operations.

Key backup changes meaning with an HSM: the key is non-exportable by design, so protecting it is the key store's job, not a file to copy. With KMS that means multi-region key replication for disaster recovery, and every use of the key appearing in the cloud audit trail. A restored Control Tower must run where it can reach the same keys; that a backup cannot be replayed outside that boundary is the property being paid for. See Keep a CA's key in AWS KMS.

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.