Trust model

In Lamassu, trust does not simply mean that a certificate exists in the inventory. A consumer trusts an identity when it can build a chain to a root it recognizes, check that the certificate is fit for the intended use and verify that it is still valid.

The four trust decisions

Who can issue

The CA hierarchy defines which authorities can sign. A root CA establishes the anchor of trust; intermediate CAs separate operating domains and avoid using the root for every issuance.

What can be issued

Certificate profiles limit validity, subject, uses, extensions and cryptographic parameters. Possessing a CA does not replace an issuance policy.

Who can request it

The DMS acts as the enrollment point. It can authenticate an EST request with a client certificate, an external webhook or a combination of both. CAs configured to validate the requester do not have to be the CA that will issue the new identity.

Who accepts the result

The consuming service or device keeps its own trust store. Lamassu can distribute the system CA, the enrollment CA and other managed CAs through /cacerts, but the consumer decides which ones it installs and how it applies validation.

Identity flow

1. The device proves it can enroll according to the DMS policy.
2. The DMS validates the request and forwards the CSR to the enrollment CA.
3. The CA applies the profile and signs without ever receiving the device's private key.
4. The device installs the certificate and the chain it needs.
5. The system that trusts the device validates the chain, dates, uses and revocation status.

Enrollment, validation and distribution CAs

A DMS relates three sets that are worth designing separately:

• Enrollment CA: signs the new identities.
• Validation CAs: authenticate the client certificates used for enrollment or migration. During re-enrollment, Lamassu tries the enrollment CA first and then the additional validation CAs.
• Distributed CAs: form the content the device obtains through EST /cacerts. You can include the system CA, the enrollment CA and a list of managed CAs.

This separation makes it possible to migrate a fleet: you temporarily accept certificates from the old hierarchy, issue with the new one and distribute both chains during the overlap.

Validation and revocation

A valid chain does not by itself guarantee that a certificate should be accepted. The consumer must also check:

• that the current date is between Not Before and Not After;
• that Key Usage and Extended Key Usage allow the operation;
• that names, SANs and subject match the expected identity;
• that the certificate does not appear revoked in OCSP or a CRL.

During the mTLS authentication of a DMS, Lamassu attempts to check revocation. If the certificate does not contain enough information to perform that check, the backend logs a warning and continues treating it as not revoked. Design your profiles and distribution points to avoid that situation in production.

Custody limits

The KMS keeps the reference to the key and delegates the operation to the configured engine. With an HSM or a cloud KMS, the private key can remain non-exportable. That protects custody, but it does not by itself prevent misuse: you still must restrict who can request a signature and audit those operations.

Recommended pattern

• Keep the root out of daily operations, or with very restricted access.
• Issue from intermediate CAs separated by environment or risk domain.
• Assign explicit profiles to every use case.
• Distribute the new trust before starting a rotation.
• Keep enough overlap to renew a disconnected fleet.
• Validate from the consuming system, not only from the Lamassu console.

Continue with CA hierarchy and rotation to turn this model into an operating procedure.