Local PKI Features¶
The Zaita platform provides a fully managed private PKI, enabling organisations to build and operate their own certificate hierarchy without running on-premises CA infrastructure. All cryptographic operations are performed within the Secured Back Control Plane — an isolated execution environment. Private key material is generated and stored there exclusively; it never traverses the front control plane or any internet-facing component.
Three-Tier CA Hierarchy¶
The Local PKI supports the standard three-tier certificate authority model:
Root Certificate Authority
│ Self-signed trust anchor
│ Private key stored in the back control plane
│
└── Intermediate Certificate Authority
│ Signed by root CA
│ Issues leaf certificates for end-entity use
│
└── Leaf Certificate
End-entity certificate
Installed on servers, services, and devices
Root CAs are the trust anchors for your organisation. Intermediate CAs sit between the root and leaf certificates, providing operational flexibility and limiting the root CA's exposure. Leaf certificates are issued to services and endpoints via certificate provisioning workflows.
Root Certificate Authorities¶
Generating a Root CA¶
Root CAs are generated directly within the back control plane. The platform creates the key pair and self-signed certificate, then stores the result. Generation is asynchronous — the platform dispatches the request and redirects to a status page while the operation completes.
Configurable generation parameters:
| Parameter | Description | Default |
|---|---|---|
| Common Name | Descriptive name for the CA (3–64 characters, unique per tenant) | — |
| Organisation | Organisation name | — |
| Organisational Unit | Department or team | — |
| Country | ISO 3166-1 two-letter country code | — |
| State | State or province | — |
| Locality | City or locality | — |
| Algorithm | Key algorithm and size (see Supported Algorithms) | ec-384 |
| Digest | Signing digest algorithm (see Supported Digests) | sha256 |
Root CA validity is set to 10 years at generation time.
Root CA Compliance Status¶
The platform tracks a compliance status for each root CA, separate from its operational status. A root CA is considered compliant when all three conditions are met:
- The root certificate has been downloaded.
- The root CA's private key has been removed from the platform.
- At least one active intermediate certificate has been issued under this root.
Reaching compliant status follows the PKI best practice of taking root keys offline once intermediates are in place.
Root CA Status Values¶
| Status | Meaning |
|---|---|
active |
Valid and operational |
revoked |
Manually revoked |
expired |
Past the certificate's validity end date |
invalid |
Failed validation checks |
unusable |
Cannot be used (for example, key material is unavailable) |
Intermediate Certificate Authorities¶
Generating an Intermediate CA¶
Intermediate CAs are generated and signed within the back control plane using a selected root CA. A signing root must be active and within its validity period to issue an intermediate.
Intermediate generation uses the same configurable parameters as root CA generation, with the addition of:
| Parameter | Description |
|---|---|
| Signing Root CA | The root certificate that will sign this intermediate |
Intermediate CA validity is set to 10 years at generation time.
Intermediate CA Status Values¶
| Status | Meaning |
|---|---|
active |
Valid and operational |
revoked |
Manually revoked |
expired |
Past the certificate's validity end date |
invalid |
Failed validation checks |
unusable |
Cannot be used (for example, key material is unavailable) |
no_root_certificate |
The signing root CA has been deleted; this intermediate is orphaned |
Supported Algorithms¶
| Value | Algorithm | Key Size |
|---|---|---|
rsa-2048 |
RSA | 2048-bit |
rsa-3072 |
RSA | 3072-bit |
rsa-4096 |
RSA | 4096-bit |
ec-256 |
ECDSA | P-256 (secp256r1) |
ec-384 |
ECDSA | P-384 (secp384r1) — default |
ec-521 |
ECDSA | P-521 (secp521r1) |
EC P-384 is the platform default. It provides strong security at smaller key sizes and is recommended for most new deployments. RSA is available where compatibility with legacy systems requires it.
Supported Digest Algorithms¶
The generation UI offers sha256, sha384, and sha512. All three are accepted by the platform:
| Algorithm | Notes |
|---|---|
sha256 |
Default. Widely accepted and suitable for most deployments. |
sha384 |
Recommended for higher-security environments. |
sha512 |
Strongest option; use for high-security or regulated environments. |
Certificate Management Actions¶
All management actions are available on the certificate detail page and are subject to role-based access control. Every action is recorded in the platform's audit log.
| Action | Available For | Description |
|---|---|---|
| Download Certificate | Root and Intermediate | Download the PEM-encoded CA certificate for trust store distribution. |
| Download Private Key | Root and Intermediate | Export the CA private key from the back control plane. |
| Delete Private Key | Root and Intermediate | Permanently remove the CA private key from the platform. Cannot be undone. |
| Delete Certificate | Root and Intermediate | Permanently delete the certificate record. Root CAs can only be deleted once all intermediate certificates issued under them have been removed. |
Tenant Limits¶
The number of root and intermediate CAs available depends on the account subscription tier:
| Tier | Root CAs | Intermediate CAs |
|---|---|---|
| Free | 1 | 2 |
| Coffee | 1 | 2 |
| Small Business | 3 | 10 |
| Medium Business | 5 | 20 |
| Enterprise | Unlimited | Unlimited |
The current usage and limit are shown in the platform's Local PKI interface, with colour-coded indicators when approaching capacity.
Access Control¶
Local PKI management requires the PKI Administrator or Super Administrator role. See Roles and Permissions for details.
Next Steps¶
- Set up your PKI — step-by-step guide to creating a root CA, intermediate CAs, and preparing for leaf certificate issuance.
- Managing Certificates — download, delete, and manage existing root and intermediate certificates.
- Best Practices — recommended hierarchy design, key management, and operational guidance.