Certification authorities

A certification authority (CA) binds identities to public keys through signed certificates. In Lamassu you can create a new hierarchy, use a key already in the KMS or incorporate an external CA.

To design a full chain or replace an authority in production, see CA hierarchy and rotation. If you need to standardize what each authority can sign, use Certificate profiles.

To administer CAs, you need authority and key permissions, a reachable engine and a reviewed profile. An external consumer does not trust a CA merely because it appears in this inventory: agree root and chain distribution separately.

Choose a flow

New CA with a new key: create a root of trust from scratch. Lamassu generates and keeps the key pair.
New CA from the KMS: reuse a key already registered in the platform.
Import a CA with its private key: incorporate an external authority that Lamassu can issue with.
Import only the certificate: register public material. If Lamassu finds its key in the KMS, it can associate it; otherwise, the CA has no usable key for issuance.

First time here? Follow Create your first CA to complete the minimal journey.

Create a new authority

Before you begin

Decide whether the CA will be a root or an intermediate.
Choose the engine that will keep the key.
Define a validity longer than that of the certificates it will issue.
For an intermediate CA, make sure the parent CA is active.

Open the wizard

In Certification Authorities, select Create New CA and choose to generate a new key pair.

Configure the key

Select the cryptographic engine, the algorithm and the size or curve. Lamassu supports RSA and EC keys according to the engine's capabilities.

Use only sizes and curves supported by the engine and the profile’s cryptographic policy. Read Keys and engines before reusing external material.

Choose the CA type

Select Root CA for a self-signed authority or Intermediate CA for an authority signed by another CA. In the latter case, choose the issuing CA.

Define the identity

Enter a unique CA Name. This name becomes the certificate's Common Name. Complete the Distinguished Name fields your policy requires:

C: two-letter ISO 3166-1 country code.
ST: state or province.
L: locality.
O: organization.
OU: organizational unit.

The CA's internal identifier is generated automatically and cannot be changed.

Configure validity and uses

Define CA Certificate Expiration and Default End-Entity Certificate Issuance Expiration. You can express a duration (5y 8w 4d), pick a date or use the maximum allowed date.

Review the CA’s own certificate separately from the default profile for certificates it will issue later. Choose an explicit issuance policy; do not assume the form’s initial values suit your consumers.

Create and verify

Confirm the form and open the CA. Check status, issuer, dates, associated engine and key. Download the certificate: it should contain CA:TRUE and a usage permitting certificate signing. Verify the self-signature for a root or the chain to your root for an intermediate. Complete a test issuance to check that the key can actually sign.

Plan validity as a hierarchy

Plan and verify expiration using the Profiles rules. Issuance does not automatically clamp validity to the issuer’s expiration; leave time to replace the authority and renew identities.

Use a key from the KMS

Select Create New CA (Existing Key) when the key is already registered in Lamassu. The wizard first asks for the backing key and then shows the same configuration of type, identity, validity and profile.

This flow is useful when the key was previously created in an HSM, imported through BYOK or must be reused under a specific custody policy.

Import an external CA

You need the CA certificate in PEM, its chain to a known root and, when importing it, an exportable private key. Before uploading material, verify signature, dates, CA:TRUE, signing usages and public-key correspondence. The key verification procedure also compares a CA key and certificate.

Select the engine

Check the installation’s default engine before importing a CA with a key. CA import delegates key import to that engine; it does not guarantee arbitrary provider selection from the form. To select an engine while importing the key separately, use the KMS.

Load the material

Import the certificate and, when applicable, its PEM key. Register the CAs needed to identify the issuer. Registering a CA does not install it in external trust stores.

Define the default issuance

Associate an explicit issuance profile if the CA will sign. Check usages and dates using Profiles.

Verify the import

Review the registered type, associated key and engine, and issuer relationship. Certificate-only import may associate an existing KMS key using the certificate’s key identifier. Without a usable key, the CA is public material and cannot sign.

For an issuing CA, complete a test issuance and check OCSP and CRL. Creating the record alone does not establish key availability, complete chain consistency or status publication.

Inspect an authority

Open a CA from the inventory to review:

Status and validity period.
Certificate and chain in PEM format.
Number of active, expired and revoked certificates.
Certificates issued in Issued Certificates.
The CRL linked to the authority.
Metadata and the associated cryptographic engine.

You can filter the inventory by name, status and CA type.

Issue certificates

You can start an issuance from Issued Certificates, from a CA's action menu or from the global certificate inventory.

Generate Key & CSR in Browser is useful for a manual operation or a quick test. The browser generates the key and you must download it at the end.

Upload Existing CSR is the right option when the key must remain on the target system. Lamassu receives the request but never the private key.

Follow Issue your first certificate for the guided flow. Certificate management explains the inventory, inspection and revocation.

Revoke a CA

Revocation affects the entire dependent chain

Revoking a CA prevents issuance and may interrupt its entire branch. Only CertificateHold allows reactivating the CA itself if it is not expired. Descendant revocation is attempted with CessationOfOperation; reactivating the parent does not restore those descendants. Follow the cascading revocation conditions.