Setting up a Private Heirarchy

A Private Hierarchy in CERTInext enables organizations to build and manage their own internal Public Key Infrastructure (PKI) by creating Root CAs and Subordinate (Issuing) CAs. This hierarchy is used to issue and manage private certificates for internal servers, devices, applications, S/MIME users, and network components.

CERTInext allows enterprises to define CA structure, validity periods, certificate profiles (Products), extensions, and approval workflows - all within a centralized interface.

Navigation Path

To create and manage a private CA hierarchy:

Certificates → Certificate Authorities → Create Private CA

From this page, administrators can create:

• Root CA

• Subordinate CA (Issuing CA)

• End Entity CA (if required for specific hierarchy design)

Step 1: Create Private CA – Choose CA Type

On the Create Private CA screen, select:

Type

• Root CA – Top-level CA that anchors the hierarchy

• Subordinate CA – CA issued and signed by a parent CA

If Subordinate CA is selected, the following must be defined:

• Parent CA – Select an existing Root CA

• Purpose

  • Issuing CA – Can issue end-entity certificates

  • End Entity Certificate – Cannot issue further certificates

Validity

Define the CA validity period (for example, 5 years, 10 years).

Note: Root CA validity should typically be longer than Subordinate CA validity.

Click Next to continue configuration.

Step 2: Configure CA Details

Define identity and operational details for the CA.

This includes:

• CA Name

• Organization details

• Country and locality attributes

• Certificate validity constraints

• Policy identifiers (if applicable)

These attributes form the subject of the CA certificate.

Step 3: Key Information

This section defines cryptographic parameters.

Typical configuration includes:

• Key Algorithm (RSA recommended)

• Key Size (e.g., 2048 or 4096 bit)

• Signature Algorithm (e.g., SHA256withRSA)

• Key usage constraints

For production-grade PKI, hardware-backed key generation using HSM is recommended where available.

Step 4: Extensions

Configure standard X.509 extensions such as:

• Basic Constraints

• Key Usage

• Extended Key Usage

• Authority Key Identifier

• Subject Key Identifier

• CRL Distribution Points

Extensions define how certificates issued by this CA can be used and validated.

Step 5: Additional Information (Optional)

Optional metadata fields may include:

• Internal references

• Business unit identifiers

• Policy descriptions

Step 6: Summary & Activation

Review the configuration before finalizing.

Once created:

• The Root CA appears in the Parent CA dropdown for subordinate creation.

• Subordinate CAs become available for product/profile configuration.

• The CA status appears as Active once successfully created.

Creating Certificate Products Under a Subordinate CA

After creating the CA hierarchy, certificate issuance is controlled through Products (Certificate Profiles).

Navigation

Certificates → Certificate Authorities → Products → Create Product

Product Configuration

Basic Details

• Product Name – Logical profile name

• Subordinate CA – Select issuing CA

• Validity (in Days) – Certificate validity period

• Certificate Template – Base template configuration

• Description – Optional reference

Setup Profile

Define the structure of certificates issued under this product.

Subject Attributes

Configure:

• Common Name (CN)

• Organization Name

• Organizational Unit

• Locality

• State

• Country

For each attribute, define:

• Presence (Mandatory / Optional)

• Data Type

• Field Restriction Type (Dynamic / Fixed)

SAN (Subject Alternative Name) Attributes

Configure:

• DNS Names

• IP Address

• Other SAN types as required

This ensures flexibility for web servers, devices, or applications requiring SAN-based validation.

Extensions

Add predefined extensions such as:

• Key Usage

• Extended Key Usage

• CRL Distribution Points

• Authority Information Access

Each extension can be configured with:

• OID

• Type

• Critical flag (if required)

Custom Extensions

If required, define:

• Custom OID

• Request Field mapping

• Data Type

• Value

• Critical flag

This allows advanced PKI use cases such as device identity or compliance tagging.

Advanced Settings

Optional controls include:

• Automatic approval of certificate requests

• Validation checklist configuration

• Approval workflow enforcement

Operational Flow

Once the Private Hierarchy and Product are configured:

1. A Subordinate CA issues certificates using the defined Product.

2. Certificates inherit:

   • Subject structure

   • SAN configuration

   • Extensions

   • Validity period

3. Issued certificates appear under:

   • Certificate inventory

   • Provisioning workflows (if integrated)

Best Practices

• Keep Root CA offline where possible.

• Use Subordinate CA for daily issuance.

• Set shorter validity for end-entity certificates.

• Enforce structured Products to maintain consistency.

• Regularly review extension configuration for compliance.

Key Notes

• Subordinate CA cannot exist without a Root CA.

• Product configuration controls certificate issuance behavior.

• Changes to Products affect future certificates only.

• All CA creation and product configuration activities are logged for audit.