Lamassu IoT DocsCertificate profiles
Define reusable policies to issue consistent certificates and constrain accepted keys.
An issuance profile turns a certificate policy into reusable configuration. Instead of deciding validity, subject, extensions and algorithms on every request, you define once what is allowed and attach the profile to a CA, a DMS or a specific issuance.
This guide is for the PKI administrator defining issuance policy. You need permissions to manage profiles and associate them with the intended CA or DMS, plus a test consumer with known identity and purpose requirements.
What a profile controls
Validity
You can express the lifetime as a duration from the moment of issuance or as a fixed end date. A duration works well for recurring identities; a common date is useful to make a whole batch end before a migration or retirement.
Plan the end date within the issuing CA’s validity and leave a renewal margin. The signer calculates the date from the profile; it does not automatically clamp validity to the issuer’s expiration. Check both dates in the resulting certificate. A fixed date in the past does not produce a usable identity either.
CA certificate or end-entity certificate
Sign as CA sets IsCA and the basic constraints needed for an authority. Enable it only in profiles intended to create or reissue subordinate CAs.
Key Usage and Extended Key Usage
The profile can enforce usages such as DigitalSignature, KeyEncipherment, CertSign, CRLSign, ClientAuth, ServerAuth or OCSPSigning.
If you enable Honor Key Usage or Honor Extended Key Usages, Lamassu keeps the values requested by the CSR. If you disable them, it replaces them with the ones defined in the profile.
Honor means delegating part of the policy
Do not enable the Honor… options for untrusted requests unless another component validates those fields. Otherwise, the requester may choose broader capabilities than intended.
Subject
With Honor Subject, the certificate keeps the subject of the CSR. Without that option, Lamassu applies the profile's CN, O, OU, C, ST and L. If the profile does not define a Common Name, the requested CN is kept.
CSR extensions
With Honor Extensions, Lamassu filters the additional requested extensions and keeps only SAN. Without that option, it discards the CSR's additional extensions.
This preserves SAN, but does not establish that the requester is entitled to those DNS names, IP addresses, emails or URIs. Validate that authorization before issuing. OCSP and CRL locations come from the issuance service configuration; Honor Extensions does not copy CSR distribution points.
Cryptographic constraints
The cryptographic enforcement can:
- allow or block RSA keys;
- limit the supported RSA sizes;
- allow or block ECDSA keys;
- limit the supported ECDSA sizes or curves.
When it is enabled, Lamassu checks the public key before creating a CA or signing a CSR. A key whose type or size is not listed in the profile is rejected.
Profile precedence
Resolution depends on the entry point. One complete profile is selected; its fields are not merged with the CA’s profile.
| Operation | First choice | Second choice | If neither is supplied |
|---|---|---|---|
| Direct signing with a CA | issuance_profile embedded in the request | Request issuance_profile_id | CA default profile (profile_id). |
| Issuance through a DMS | settings.issuance_profile_id | settings.issuance_profile embedded in the DMS | Enrollment CA default profile. |
If the selected identifier cannot be resolved, the operation fails; it does not silently fall back to the CA’s profile. Avoid setting both options at once. Recording which profile was selected helps explain why a certificate differs from its CSR.
Several fleets can share a CA while keeping different profiles through their DMSs. Requester authentication and device registration policy are configured separately in DMS.
Create a profile
Define a single purpose
Separate, for example, mTLS devices, servers and intermediate CAs. A small, specific profile is easier to review than one that allows every use.
Choose the validity
Align the duration with the fleet's real renewal capacity. Leave margin against the CA's expiration.
Fix usages and subject
For a device that authenticates as a client, the usual starting point is DigitalSignature and ClientAuth. Add ServerAuth or KeyEncipherment only if the protocol needs it.
Constrain the keys
Enable cryptographic enforcement and list only algorithms and sizes compatible with your policy and your devices.
Attach it and test
Attach the profile to a CA or DMS and check the precedence above. Issue a CSR with known usages and SAN; inspect the result with openssl x509 -in device.crt -noout -text. Check subject, SAN, KU, EKU and dates. For an end-entity identity, disable Sign as CA, require no CA:TRUE or Certificate Sign, and require CA:FALSE if Basic Constraints is present.
Also try a key excluded by policy: issuance should fail. Follow the certificate verification and test acceptance in the intended consumer.
Design examples
mTLS device
End-entity certificate, short validity, DigitalSignature, ClientAuth, subject controlled by the DMS and SAN allowed when it identifies the device.
TLS server
End-entity certificate, DigitalSignature, ServerAuth and mandatory SAN with the names clients will use.
Intermediate CA
Sign as CA, CertSign and CRLSign, validity longer than its end-entity certificates and stricter cryptographic constraints.
These patterns express design decisions. Enabling Honor Extensions does not require a CSR to contain SAN or validate its names; enforce that in the request workflow. A profile does not install trust or grant permissions in the consumer.
Changes and deletion
Updating a profile affects future issuances; it does not modify already-signed certificates. Test changes before applying them to a CA in production and keep the operational justification.
Before deleting a profile, check that no CA or DMS depends on it. If you want to replace it, create the new version, update the references and perform a test issuance before retiring the old one.