Home / Client PKI
CLIENT PKI

Client PKI

Build and operate a private certification hierarchy per organization: root, intermediate and issuing authorities, profiles, CSR requests, issued certificates, revocation, CRL, OCSP and audit.

On this page 1. What the module provides 2. Choose the PKI hierarchy 3. Create a managed root 4. Import an offline root 5. Create a child authority 6. Create a certificate profile 7. Submit a CSR 8. Approval and issuance 9. Revocation, CRL and OCSP 10. Available algorithms 11. Common errors

1. What the module provides

The Client PKI dashboard groups certification authorities, issued certificates, revoked certificates and post-quantum authorities for your organization. Main interface actions include New Managed Root, Import an Offline Root, New Child Authority, New Profile and Submit a CSR.

PKI objects are isolated by organization. A request cannot use a profile or authority owned by another organization.

2. Choose the PKI hierarchy

Ecurem CLM distinguishes three authority types:

Important rule: an issuing authority cannot sign another authority. An intermediate authority may only create an issuing authority. When the PKI issuing-CA control is enabled, end-entity certificates must be issued by an Issuing authority.

A common hierarchy is Root → Intermediate → Issuing → End-entity certificates.

3. Create a managed root

From Client PKI, select New Managed Root. The form asks for:

After creation, Ecurem CLM creates the self-signed root, protects the private key in the configured backend, generates an initial CRL and prepares an OCSP responder.

4. Import an offline root

Use Import an Offline Root when the root is created and kept outside Ecurem CLM. The platform can reference the root certificate and build the operational hierarchy without holding that root private key.

This model is useful when policy requires an offline trust anchor. Daily issuance can then be delegated to an intermediate or issuing authority.

5. Create a child authority

Select New Child Authority. Fields are:

The actual child validity cannot exceed the parent’s remaining lifetime. The platform also enforces X.509 path-length and CA constraints.

6. Create a certificate profile

Select New Profile and configure:

In the current customer interface, the technical usages are initialized for TLS server certificates with digitalSignature and serverAuth.

7. Submit a CSR

The Submit a CSR form asks for exactly:

The CSR must be valid PKCS#10 PEM, have a valid cryptographic signature, contain a Common Name and comply with the selected profile. Common Name and Subject Alternative Names are parsed from the CSR.

8. Approval and issuance

Request states include Pending, Approved, Rejected, Issued and Failed.

If the profile requires approval, the request must be explicitly approved before issuance. The authority must be enabled, non-revoked and in the same organization. When the issuing-CA requirement is enabled, the selected authority must be of type Issuing.

After issuance, Ecurem CLM stores the serial number, certificate PEM, chain, SHA-256 fingerprint, validity dates and source request.

9. Revocation, CRL and OCSP

Revocation records include the reason, revocation time and actor. The module also maintains signed CRLs, delegated OCSP responders and PKI audit events containing organization, actor, action, object, outcome and useful details.

Before production use, ensure public CRL and OCSP URLs are correctly defined and reachable by relying systems.

10. Available algorithms

Select algorithms according to cryptographic policy and relying-party compatibility. Post-quantum support should be validated end to end before operational use.

11. Common errors