Lamassu IoT DocsCA hierarchy and rotation
Design root and intermediate authorities and replace certificates or keys without breaking trust.
The hierarchy determines the blast radius of any error or compromise. A root signs intermediate CAs; intermediates issue the identities used by devices and services. This separation lets you isolate environments and rotate a branch without replacing all trust.
Design the hierarchy
For a production installation, use a very restricted root and one or more operational intermediates. Separate intermediates when any of these boundaries change:
- environment, such as production and preproduction;
- owner or operating team;
- device family or manufacturing process;
- region or regulatory requirement;
- cryptographic engine or key policy;
- maintenance window and renewal cadence.
Avoid deep hierarchies without a concrete need. Each level adds chain distribution, validation and one more certificate you must renew.
Validity descends through the hierarchy
A child CA and its end-entity certificates must expire before their issuer. Reserve a margin that allows distributing another chain and renewing dependent certificates.
Reissuance and rotation are not the same
Reissuing a CA creates a new certificate over the existing key. Lamassu generates a CSR with that key, self-signs it if it is a root or asks the parent CA to sign it if it is subordinate. The new certificate becomes active and the CA points to its serial number; the old and new certificates are linked through metadata.
Rotating a CA creates a successor key and authority. It is the right choice in the face of compromise, a cryptographic change, an engine migration or non-exportable key policies.
Lamassu does not allow reissuing an already-revoked CA or a CA whose expiration date has passed. Plan ahead for both conditions.
When to choose each operation
- Reissue if the key is still trustworthy and you only need another validity period or an updated certificate.
- Rotate the key if compromise is suspected, the algorithm changes or you want to move custody to another engine.
- Create a parallel branch if you cannot update all consumers at the same time.
- Revoke immediately only when the risk of keeping the CA outweighs the impact of interrupting the fleet.
Key rotation procedure
Inventory the dependencies
Locate child CAs, issued certificates, DMSs, connectors and external trust stores. Include devices that may stay offline for weeks or months.
Create the successor CA
Generate a new key in the planned engine, create the CA and assign it an explicit profile. Do not reuse the operational identifier to hide that it is a different generation.
Distribute the new trust
Add the new root or chain to consumers before issuing with it. In a DMS, use the managed CAs of /cacerts to temporarily keep both the old and new chains.
Switch issuance
Update the enrollment CA and profile of the DMSs. Keep the additional validation CAs if old certificates still need to be accepted during re-enrollment.
Renew in batches
Migrate a small cohort, validate mTLS, OCSP and CRL from the consumer and expand progressively. Monitor which devices still present the old chain.
Close the overlap
Once no legitimate consumer depends on the previous authority, remove it from issuance and from the distributed CAs. Revoke it if policy requires it.
Cascading revocation
When you revoke a CA, Lamassu also updates its child CAs and issued certificates to REVOKED with the reason CessationOfOperation. The children's revocations propagate the effect to their own branches.
This protects the coherence of the hierarchy, but it makes revocation a high-impact action. Do not use it as the ordinary mechanism to stop issuing: first complete the migration and remove the CA from operational flows.
Checks after the change
- The new chain ends in an anchor installed by the consumer.
- New certificates contain the expected AKI, SKI, KU, EKU and SAN.
- The DMS delivers the correct chain through EST
/cacerts. - Re-enrollment accepts the old identity during the planned period.
- OCSP and CRL respond for the authorities that remain active.
- No DMS is left accidentally issuing from the old CA.
See the Trust model to understand the DMS's CA sets and Certificate lifecycle for states and revocation effects.