PKI Best Practices¶

This page outlines recommended practices for building and operating a secure, maintainable private PKI on the Zaita platform. These guidelines apply to organisations of all sizes and are aligned with industry standards for certificate lifecycle management.

Hierarchy Design¶

Use a Two-Tier or Three-Tier Hierarchy¶

Never issue leaf certificates directly from a root CA. Use at least one layer of intermediate CAs between the root and end-entity certificates. This limits root CA exposure and allows the root private key to be taken offline.

A two-tier hierarchy (root → intermediate → leaf) is suitable for most organisations. Larger or more regulated environments may benefit from a three-tier hierarchy, introducing a policy CA layer between the root and issuing intermediates.

Segment Intermediates by Purpose¶

Create separate intermediate CAs for distinct operational domains. Common segmentation patterns include:

By environment — production, staging, development.
By certificate type — TLS server certificates, client authentication, code signing, internal services.
By business unit or team — when different groups have different compliance or operational requirements.

Segmentation limits the blast radius of a compromise and simplifies revocation — revoking a single intermediate does not affect certificates issued by other intermediates under the same root.

Keep the Number of Root CAs Small¶

Most organisations need only one or two root CAs. Additional roots increase the complexity of trust distribution and key management. Create a new root only when there is a clear operational or compliance reason, such as separating internal and external trust domains.

Root CA Security¶

Take Root Private Keys Offline¶

Once intermediate certificates have been issued, remove the root CA's private key from the platform and store it securely offline — in a physical HSM, an air-gapped system, or a secure vault. The root private key should only be brought back online to issue or renew intermediate certificates, or to revoke a compromised intermediate.

On the Zaita platform, a root certificate is considered compliant only when its private key has been removed, the certificate has been downloaded, and at least one active intermediate exists. Aim to reach compliant status as soon as your intermediates are in place.

Set Long Validity Periods for Root Certificates¶

Root certificates should have long validity periods — typically 10 to 20 years. A root expiry forces re-provisioning of the entire chain of trust, including all intermediates and leaf certificates, and redistributing the new root to every trust store.

Maintain Verified Backups of Root Keys¶

Before deleting a root private key from the platform, ensure you have a verified, tested backup in a secure offline location. A lost root key means the entire chain of trust under that root must be rebuilt from scratch.

Intermediate CA Management¶

Set Shorter Validity Periods for Intermediates¶

Intermediate certificates should have shorter validity periods than their parent root — typically 3 to 10 years. Shorter lifetimes reduce the window of exposure if an intermediate key is compromised and align with the principle of regular key rotation.

Limit Intermediate CA Scope with Policies¶

Use the platform's policy engine to restrict what each intermediate CA can issue. Policies can constrain algorithm, key size, validity period, and allowed domains. This enforces consistency and prevents intermediates from issuing certificates outside their intended scope.

Monitor Intermediate CA Status¶

Regularly review the status of your intermediate certificates in the web portal. The platform tracks each intermediate as active, revoked, expired, or invalid. Set up processes to renew intermediates well before expiry to avoid disruption to leaf certificate issuance.

Leaf Certificate Practices¶

Use Short Validity Periods¶

Leaf certificates should have the shortest practical validity period — 90 days to 1 year is common for TLS certificates. Shorter lifetimes limit the window of exposure from a compromised key and encourage automation of renewal workflows. Industry standards are trending toward 90-day maximums for publicly trusted certificates; applying the same discipline to private certificates strengthens your security posture.

Automate Issuance and Renewal¶

Manual certificate management does not scale and is prone to human error, missed renewals, and outages. Use the platform's automation capabilities to eliminate manual handling:

Bridges for push-based provisioning and deployment to target systems.
Couriers for pull-based delivery, especially in CI/CD pipelines and scheduled workloads.
REST API for custom integrations and orchestration.

See Bridges, Couriers, and Features for details.

Generate Key Pairs Close to Where They Are Used¶

Wherever possible, generate key pairs on the system that will use the certificate — on the target system itself, on a Bridge within the same network, or within a customer-managed HSM. This avoids the need to transport private keys across networks.

When key pairs must be generated centrally (for example, in the platform's Secured Back Control Plane), always require the requestor to provide an encryption key so the private key is encrypted before delivery.

Include Only Necessary SANs¶

Subject Alternative Names (SANs) should include only the identities the certificate needs to cover. Avoid wildcard certificates unless there is a clear operational need — wildcards increase the risk of certificate misuse if the private key is compromised.

Cryptographic Algorithm Selection¶

Prefer Elliptic Curve for New Deployments¶

EC P-384 is the platform default and is recommended for most new deployments. EC keys offer equivalent security strength to RSA at significantly smaller key sizes, resulting in faster TLS handshakes and reduced computational overhead.

Use RSA (3072 or 4096 bits) where compatibility with legacy systems is required. Avoid RSA 2048 for new deployments — while still widely accepted, it offers a lower security margin and is being phased out by many standards bodies.

Use Strong Digest Algorithms¶

SHA-256 is the minimum recommended digest algorithm. Use SHA-384 or SHA-512 for higher-security applications. Avoid SHA-1 entirely — it is cryptographically broken and no longer accepted by modern trust stores.

Align Algorithm Choices Across the Hierarchy¶

While the platform allows different algorithms at each level of the hierarchy, using a consistent algorithm family (for example, EC throughout) simplifies validation and reduces compatibility surprises. If you do mix algorithms, ensure all systems in your environment support the algorithms used at every level of the chain.

Key Management¶

Use the Secured Back Control Plane or an External HSM for Sensitive Keys¶

For certificate authorities and high-value workloads, generate and store keys within the platform's Secured Back Control Plane or an integrated third-party HSM. HSM-backed key storage ensures that private key material is never exposed in memory outside a hardened boundary.

Rotate Keys on Renewal¶

When renewing a certificate, generate a new key pair rather than reusing the existing one. Key rotation limits the impact of any undetected key compromise and aligns with cryptographic best practice.

Each system, service, or application should have its own unique certificate and key pair. Sharing private keys between systems increases the blast radius of a compromise and makes revocation difficult without disrupting unrelated services.

Discovery and Inventory¶

Enable Automated Discovery¶

Enable both Certificate Transparency log scanning and HTTPS endpoint scanning to maintain a complete, current view of your certificate estate. Automated discovery surfaces unknown, unexpected, or rogue certificates that may have been issued outside your PKI.

Review the Inventory Regularly¶

Schedule regular reviews of your certificate inventory. Look for:

Certificates approaching expiry that have not been queued for renewal.
Certificates issued with weak algorithms or short key sizes.
Certificates with unknown or unexpected issuers.
Certificates that are no longer in use and should be revoked.

Register All Domains¶

Register all domains your organisation uses with the platform. Domain registration is required for certificate issuance and discovery. Unregistered domains create blind spots in your inventory.

Access Control¶

Enforce Least Privilege¶

Assign roles with the minimum level of access required for each user's responsibilities. Certificate requestors should not have administrative access to root or intermediate CA management. Use the platform's RBAC model to enforce separation of duties.

Use Machine Accounts for Automation¶

All programmatic access — Bridges, Couriers, API integrations — should authenticate using dedicated machine accounts, not user accounts. Machine accounts support IP whitelisting and federated identity, reducing the risk of credential leakage.

Prefer Federated Identity for Machine Accounts¶

Where your infrastructure supports it, use federated identity (SPIFFE, Azure Workload Identity, AWS OIDC) for machine account authentication. Federated identity eliminates long-lived static credentials and simplifies key rotation.

Audit and Compliance¶

Monitor Audit Logs¶

Review audit logs for unexpected or unauthorised activity, including:

Root or intermediate CA key downloads or deletions.
Certificate revocations.
Changes to policies, roles, or machine account configurations.
Failed authentication attempts.

Integrate with Your SIEM¶

Export audit logs to your organisation's SIEM platform for correlation with broader security monitoring. SIEM integration enables automated alerting on anomalous certificate operations and supports compliance reporting.

Document Your PKI¶

Maintain documentation of your PKI hierarchy, the purpose of each CA, key custody procedures, and revocation processes. Clear documentation is essential for incident response, audits, and onboarding new team members.

Summary¶

Practice	Recommendation
Hierarchy	Two-tier minimum; segment intermediates by purpose
Root CA keys	Take offline immediately; maintain verified backups
Root validity	10–20 years
Intermediate validity	3–10 years
Leaf validity	90 days to 1 year
Algorithm	EC P-384 for new deployments; RSA 3072+ for legacy compatibility
Digest	SHA-256 minimum; SHA-384 or SHA-512 preferred
Key generation	Generate close to the point of use; use HSM for CA keys
Automation	Use Bridges, Couriers, or API for all issuance and renewal
Access control	RBAC with least privilege; federated identity for machine accounts
Discovery	Enable CT log and endpoint scanning; register all domains
Audit	Monitor logs; integrate with SIEM; document your PKI