CA Hierarchy¶

In the UI the CA Hierarchy page provides a visual interface for browsing the Certificate Authority structure in the PKI system. It shows how Root CAs, Intermediate CAs, and Issuing CAs are organized and allows you to inspect detailed information about each CA, create new CAs, and act on pending CA operations.

Overview¶

The CA Hierarchy page is the starting point for exploring your PKI infrastructure. It displays a table listing all Root Certificate Authorities registered in the platform.

The table shows the following information for each root CA:

Column	Description
Name	The CA name. Grouped roots show a badge with the number of roots in the group.
Status	Active or Revoked (color-coded)
Subject DN	The distinguished name of the CA
Hierarchy Depth	How many levels deep the CA hierarchy extends
Sub CAs	Number of subordinate certificate authorities
Actions	Menu to view the full hierarchy tree, download the CSR, or upload an issued certificate

Root CAs that share the same root group (e.g., multiple SRK roots in an (A)HAB use case) are automatically grouped into a single row with aggregated metrics.

Tip

Click on any row to open the hierarchy tree dialog and see the full CA structure.

Hierarchy View¶

Clicking a root CA row opens a dialog displaying the full hierarchy tree. The tree visualizes the complete chain from the Root CA through Intermediate CAs down to Issuing CAs.

Tree Node Information¶

Each node in the tree displays:

CA name — Name of the CA
Status badge — Active (green) or Revoked (red)
CA type badge — Root CA, Intermediate CA, or Issuing CA
Subject DN — Subject Distinguished Name
Key and Signature algorithm
Validity period — Not Before and Not After dates
Certificates issued — count of certificates issued by this CA (if any)

Interacting with the Tree¶

Click any node to open a detail dialog with comprehensive technical information.
View Certificates — from the detail dialog, navigate to the certificates page filtered by that CA.
View Profile — from the detail dialog, navigate to the associated PKI profile.
Trust Chain — the detail dialog shows the full issuer chain from the selected CA up to the root.
Node actions menu — the three-dot menu on each tree node exposes per-CA actions such as Download CRL, Generate CRL, and Issue Certificate (see Tree Node Actions).

Note

For grouped roots (e.g., SRK groups), the tree dialog loads and displays all roots in the group simultaneously.

CA Types¶

Certificate Authorities are organized in three levels, each with a distinct visual style in the hierarchy tree:

Type	Icon Color	Description
Root CA	Blue	The trust anchor at the top of the hierarchy. Self-signed certificates that establish the root of trust.
Intermediate CA	Purple	Mid-level CAs that bridge Root and Issuing CAs. Also called Sub CAs.
Issuing CA	Green	Leaf CAs that directly issue end-entity certificates to devices, users, or services.

Status Indicators¶

Status	Color	Meaning
Active	Green	The CA is valid and operational
Pending	Orange	The CA product has been created but no certificate has been issued or uploaded yet
Revoked	Red	The CA has been revoked and is no longer trusted
Expired	Orange	The CA certificate is past its `Not After` date

CA Detail Information¶

When you click a CA node, the detail dialog shows two columns of technical information:

Identity & Certificate:

CA type (Root, Intermediate, or Issuing)
Serial number
Subject DN
Issuer DN

Technical Details:

Key algorithm (e.g., RSA 2048, ECDSA P256)
Signature algorithm
Valid From / Valid Until dates
Number of certificates issued
CRL Expiry and CRL Issue Interval (if configured)
Associated PKI profile

The detail dialog also displays the full trust chain — the complete issuer path from the selected CA up to the root.

Tip

Use the View Certificates button in the detail dialog to quickly find all certificates issued by a specific CA. This filters the certificates list by the CA's Authority Key Identifier (AKI).

Create CA¶

New CAs are created from the CA Hierarchy page using the New CA (+) button in the header. The page opens a guided wizard that walks through the type selection, issuer selection (for Sub CAs), CA information, operation definition, and a final confirmation step.

Three CA creation flows are supported. Pick the one that matches what you want to add to the hierarchy:

Option	What it does	When to use
Root CA for the system	Creates a new self-signed Root CA managed entirely by the platform.	You need a new trust anchor that the platform will issue from directly.
Sub CA for the system	Creates a new Sub CA and immediately submits a CSR to an issuer CA that already exists in the platform.	You want a new intermediate or issuing CA chained under an existing platform Root or Sub CA.
Sub CA from an external root	Creates a Sub CA whose CSR is exported for signing by a Root or Sub CA that lives outside the platform. The signed certificate chain is uploaded afterwards.	You operate the parent CA elsewhere (e.g., an offline HSM-protected root).

Approvers and groups

Every CA creation flow defines an Issue Certificate operation with allowed, approval, and blanket groups. The same access-control model used elsewhere in the platform applies — only members of the configured groups can submit, approve, or skip approval for certificate issuance.

Wizard Steps¶

The wizard is the same across all three flows. The Select Issuer step only appears for Sub CA for the system, since that is the only flow where the platform needs to know which existing CA must sign the new Sub CA's CSR.

Select CA Type — pick Root, Sub CA, or Sub CA from external.
Select Issuer (Sub CA for the system only) — pick the parent Root or Sub CA and the Issue Certificate operation that should sign the new Sub CA.
CA Information — name, description, common name, key type, PKI profile, and CRL configuration.
Operation & Approval Rules — define the Issue Certificate operation the new CA will expose, including its profile and approval groups.
Confirmation — review the request.
Create — submit. For Sub CA for the system, the wizard automatically waits for the CA product to become Ready, then issues the certificate via the selected issuer operation.

Create a Root CA¶

Use this flow to add a new self-signed Root CA.

Navigate to Products & PKI > CA Hierarchy.
Click New CA.
Select Create Root CA for the system and click Continue.

Fill in the CA Information fields:

Field	Required	Description
Name	Yes	Short product name shown in the hierarchy list. Maximum 250 characters.
Description	No	Free-form description.
Common Name	Yes	CN that goes into the CA's Subject DN.
Key Type	Yes	One of `RSA2048`, `RSA3072`, `RSA4096`, `ECDSAP256`, `ECDSAP384`, `ECDSAP521`.
Profile	Yes	A PKI profile of type Root CA. The selected profile defines DN template, key usage, validity, and other extensions.
CRL Configuration	No	See CRL Configuration.

Click Continue and define the Issue Certificate operation and its approval rules (see Approval Rules).
Review the request on the Confirmation step and click Send for Approval.
Once approved, the platform generates the key pair and self-signs the Root certificate. The new CA appears in the hierarchy as Active.

Create a Sub CA (for the system)¶

Use this flow to add a Sub CA that is signed by an existing CA inside the platform.

Navigate to Products & PKI > CA Hierarchy and click New CA.
Select Create Sub CA for the system and click Continue.
On Select Issuer:
- Choose the Root CA to start from.
- The full hierarchy tree of that root is rendered. Click the CA node that should sign the new Sub CA. Only nodes that expose an Issue Certificate operation are selectable.
- Pick the Issue Certificate operation that should be used for the signing.
Fill in the CA Information fields. The Profile drop-down is filtered to Sub CA profiles for this flow.
Define the Issue Certificate operation and its approval rules.
Review and click Create And Issue.

The wizard then:

Creates the new CA product.
Polls the product until its state becomes Ready (which means the CA has produced a CSR).
Submits the CSR to the selected issuer operation, producing the signed Sub CA certificate.

Approval may pause the wizard

If the selected issuer operation requires approval and the submitting user is not in a blanket group, the issuance moves to Pending under Certificate Signing Request Approvals. The new Sub CA only becomes Active after an approver promotes the request.

Create a Sub CA from an External Root¶

Use this flow when the parent CA is outside the platform.

Navigate to Products & PKI > CA Hierarchy and click New CA.
Select Create Sub CA from an external root and click Continue.
Fill in the CA Information and operation/approval fields as for any other Sub CA.
Submit. The platform generates the key pair and produces a CSR. The new entry appears in the hierarchy with status Pending.
Open the actions menu on the pending row and select Download CSR. Send the downloaded CSR to your external signing process.
Once the external root returns the signed chain, open the actions menu again and select Upload Issued Certificate. Paste the PEM-encoded certificate chain (issuing CA first, root last) into the dialog and click Upload.

The chain is verified and stored against the Sub CA. On success, the entry transitions from Pending to Active.

Submit complete chains

The uploaded PEM bundle must contain the new Sub CA certificate plus every intermediate up to (and including) the external root. Incomplete chains are rejected at upload time.

CRL Configuration¶

Both Root and Sub CA wizards expose CRL settings on the CA Information step. CRL configuration is optional — leave the fields empty if the CA will not publish a CRL.

Field	Description
CRL Expiry	Validity duration of each generated CRL (e.g., `8760h` for one year).
CRL Issue Interval	How often the platform automatically re-issues the CRL.
CRL Distribution Points	One or more URLs published in the CRL Distribution Points extension of certificates issued by this CA. Use the `+` button to add another URL and `-` to remove one.
Policy Identifiers	One or more OIDs published in the Certificate Policies extension. Same `+` / `-` controls as for distribution points.

Match the URLs to your hosting

CRL Distribution Points must point at URLs that actually serve the CRL bytes. The platform hosts CRLs that you generate from the tree menu (Generate CRL / Download CRL), but the URL itself must be set up by your operations team or referenced through an external mirror.

Approval Rules¶

Each CA creation request defines an Issue Certificate operation that the new CA will expose to consumers. The operation carries an Approval Rule that controls who can request and approve certificate issuance.

Fields collected on the Operation & Approval Rules step:

Field	Required	Description
Operation Name	Yes	Short name shown to clients that select this operation. Maximum 250 characters.
Operation Description	No	Free-form description.
Profile	Yes	A PKI profile of type Sub CA or End Entity. Defines what kind of certificates this operation will issue.
Rule Name	Yes	Name of the approval rule. Used in audit trails.
Rule Description	No	Free-form description of the rule's intent.
Allowed Groups	At least one	Identity-provider groups whose members may submit an issuance request.
Approval Groups	At least one	Groups whose members may approve an issuance request submitted by an Allowed group member.
Blanket Groups	Optional	Groups whose members can submit and immediately have the request auto-approved without a separate approver.

The two-person principle is enforced by default: a member of an Allowed group submits, and a member of an Approval group approves. Blanket groups exist for automation and trusted internal flows where a separate approval step would be redundant.

Blanket access bypasses the four-eyes review

Anyone in a Blanket group can issue certificates without a second approver. Limit Blanket group membership to service accounts or roles where this is explicitly intended.

For the approval list itself, see Certificate Signing Request Approvals.

Tree Node Actions¶

The three-dot menu on each CA node in the tree exposes operations available on that node. The visible items depend on the CA's role and status.

Action	Available when	Effect
Download CRL	The CA has published at least one CRL	Downloads the latest CRL as a `.crl` file.
Generate CRL	The CA can issue CRLs	Triggers a new CRL generation. The new CRL becomes available for download once the job completes.
Issue Certificate	The CA exposes an Issue Certificate operation	Opens a dialog where you can pick an operation and paste a PEM CSR. The submitted CSR follows the operation's approval rule.

The CA Hierarchy overview list also exposes per-row actions:

Action	Available when	Effect
View Hierarchy	The CA is not in `Pending` state	Opens the hierarchy tree dialog for that root.
Download CSR	The CA is in `Pending` state and has a CSR (typical for external-root Sub CAs)	Downloads the CA's CSR for offline signing.
Upload Issued Certificate	The CA is in `Pending` state	Opens the upload dialog to attach the signed certificate chain returned by the external root. See Create a Sub CA from an External Root.

Issue a Certificate from the Tree¶

This is the same flow that backs the Issue Certificate button.

Open the hierarchy of the relevant Root CA.
Open the three-dot menu on the CA node that should issue the certificate.
Click Issue Certificate.
In the dialog, pick one of the CA's Issue Certificate operations.
Paste the PEM-encoded CSR into the CSR (PEM) field.
Click Submit.

The request follows the operation's approval rule. If approval is required, the new request appears under Certificate Signing Request Approvals.

Best Practices¶

Plan CA validity and depth

Root CAs are long-lived and expensive to replace. Pick a Root CA validity that significantly outlasts every Sub CA that will chain under it, and constrain the hierarchy depth in the PKI profile (Max Path Length) so that the structure cannot grow unboundedly.

Use descriptive names. Include the CA role and a date in the request name, e.g. Device Issuing CA 2026-Q2. Audit trails and the hierarchy list are far easier to read.
Pair profiles with intent. Root CA profiles should only allow Sub CA signing; Sub CA profiles can additionally allow end-entity issuance. The profile drop-down in the wizard is already filtered to the matching profile type — do not work around it by picking a non-matching profile.
Separate Allowed and Approval groups. Configuring the same identity-provider group as both Allowed and Approval defeats the two-person principle.
Limit Blanket group membership. Reserve Blanket groups for automation accounts that genuinely cannot wait for a human approver.
Stage external-root rollovers. When rotating an external root, create the new Sub CA first, upload the new chain, and migrate consumers before retiring the previous Sub CA.

For more information about configuring CA profiles, see PKI Profiles. For the full PKI technical documentation, see the PKI General Guide.