Skip to content

Introduction to Public Key Infrastructure

Public Key Infrastructure (PKI) is a framework of roles, policies, hardware, and software used to create, manage, distribute, and revoke digital certificates. PKI establishes a chain of trust that enables systems, services, and users to verify each other's identity and communicate securely over untrusted networks.

At its core, PKI relies on asymmetric cryptography — a pair of mathematically related keys where one key encrypts and the other decrypts. The public key is embedded in a digital certificate and shared openly; the private key is kept secret by its owner. A certificate authority (CA) vouches for the binding between a public key and an identity by digitally signing the certificate, creating a verifiable chain of trust back to a known root.

PKI on the Zaita Platform

The Zaita platform provides a fully managed private PKI, enabling organisations to create and manage their own certificate authorities, issue certificates, and govern the entire certificate lifecycle from a single interface.

Key capabilities include:

  • Root and intermediate CA management — create or import root certificate authorities, then issue intermediate CAs beneath them to build a complete chain of trust.
  • Configurable cryptographic algorithms — generate keys and certificates using RSA (2048, 3072, 4096), Elliptic Curve (P-256, P-384, P-521), and a wide range of digest algorithms.
  • Secured Back Control Plane — all key generation and signing operations are performed within the platform's isolated back control plane, with FIPS 140-3 (Level 1) compliance. Third-party physical and cloud HSMs (Azure, AWS) are also supported.
  • Compliance enforcement — the platform ensures root certificates meet operational best practices before they are considered compliant.
  • Unlimited issuance — issue as many root, intermediate, and leaf certificates as your organisation requires, with no per-certificate fees.

For a full overview of platform capabilities, see Features.

The Chain of Trust

PKI organises certificates into a hierarchical chain of trust. Each level in the hierarchy serves a distinct purpose, and trust flows downward from the root through intermediates to leaf certificates.

Root Certificates

A root certificate is the trust anchor at the top of the certificate hierarchy. When a root certificate is loaded into a system's trust store, every certificate issued by that root — or by any of its intermediates — is implicitly trusted.

Because of their critical role, root certificates require careful handling:

  • Root CAs should not issue leaf certificates directly. Instead, they issue intermediate certificates, which in turn issue leaf certificates for general use.
  • Once intermediate certificates have been created, the root CA's private key should be taken offline — removed from the platform and stored securely (for example, in a physical HSM or an air-gapped system).
  • On the Zaita platform, a root certificate is considered compliant only when its private key has been removed from the platform, the certificate has been downloaded, and at least one active intermediate certificate exists.

Root certificates can be generated directly within the platform or uploaded from an existing PKI infrastructure.

Intermediate Certificates

Intermediate certificates sit between the root and the leaf certificates in the chain of trust. They are signed by a root CA (or by another intermediate) and are used to issue leaf certificates for end-entity use.

Using intermediate certificates provides several operational and security advantages:

  • Limits root CA exposure — the root CA's private key can remain offline while intermediates handle day-to-day issuance.
  • Enables segmentation — different intermediates can be created for different environments, teams, or purposes (for example, one for production TLS certificates, another for internal services, and a third for code signing).
  • Supports revocation without root impact — if an intermediate is compromised, it can be revoked without affecting the root CA or other intermediates.

On the Zaita platform, intermediate certificates maintain a chain-of-trust relationship with their parent root. The platform tracks their status across the full lifecycle — active, revoked, expired, invalid, or unusable. If the signing root CA is deleted, the intermediate enters a no_root_certificate state and can no longer be used for issuance.

Leaf Certificates

Leaf certificates (also called end-entity certificates) are the certificates installed on servers, devices, applications, and services. They are the final link in the chain of trust and are not used to sign other certificates.

A leaf certificate contains:

  • The subject — the identity of the entity (for example, a domain name or service).
  • The public key — used by clients to establish encrypted communication.
  • The issuer — the intermediate (or root) CA that signed the certificate.
  • Validity dates — the window during which the certificate is considered trustworthy.
  • Subject alternative names (SANs) — additional identities covered by the certificate.

When a client connects to a service presenting a leaf certificate, it verifies the certificate by walking the chain: the leaf was signed by an intermediate, the intermediate was signed by the root, and the root is in the client's trust store. If every link in the chain is valid and trusted, the connection is established.

On the Zaita platform, leaf certificates can be provisioned manually or through fully automated workflows using Bridges and Couriers. Key pairs can be generated on the target system, on a Bridge, or within the platform's Secured Back Control Plane — giving organisations flexibility to match their security requirements.

Next Steps