CA hierarchy and rotation

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.

This procedure is for the PKI operator replacing an authority in use. You need access to CAs, keys and profiles, a dependency inventory and coordination with trust-store and device owners. Before switching issuance, prepare a test cohort and decide the criterion for ending overlap.

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.

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

Cascading revocation

Lamassu saves the CA’s revocation, then attempts to revoke child CAs and issued certificates with CessationOfOperation. Propagation continues recursively through child CAs. This is not a transaction over the whole hierarchy: some resources may have changed while other updates failed.

Resources in EXPIRED state and resources already revoked for a final reason reject further status transitions. Per-descendant failures are logged; review the inventory and logs even when the parent operation completes.

CertificateHold allows reactivating the parent while it is not expired, but does not restore child CAs or certificates permanently revoked during the cascade. Holding a CA therefore does not provide a reversible pause for its entire branch.

Before closing the change, compare the original dependency inventory with final states and verify revocation publication for each issuer. Do not use revocation as the ordinary mechanism to stop issuance: complete 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.