Skip to content

Setting Up Your PKI

This guide walks through the process of establishing a private Public Key Infrastructure on the Zaita platform. By the end, you will have a root certificate authority, at least one intermediate CA, and be ready to issue leaf certificates.

All key pairs generated by the platform are created and stored exclusively within the back control plane — an isolated execution environment with no externally accessible interfaces. Private key material never traverses the SaaS control plane or any internet-facing component. For more information on the platform's architecture and key storage model, see Architecture and Security.

For background on PKI concepts and terminology, see Introduction to PKI.

Prerequisites

Before you begin, ensure the following:

  • You have an active Zaita account. See Creating an Account.
  • You are signed in to the web portal. See Signing In.
  • Your user account has the PKI Administrator or Super Administrator role.

Planning Your PKI Hierarchy

Before creating certificates, consider the structure of your PKI hierarchy. A typical setup includes:

  • One or more root CAs — the trust anchors for your organisation. Each root CA represents an independent chain of trust.
  • One or more intermediate CAs per root — used for day-to-day certificate issuance. Intermediates can be segmented by environment, team, or purpose.

A common starting configuration:

Root CA
├── Intermediate CA — Production
├── Intermediate CA — Staging
└── Intermediate CA — Internal Services

Plan your hierarchy before creating certificates. While the platform supports adding roots and intermediates at any time, a well-structured hierarchy from the outset simplifies certificate management, policy enforcement, and revocation.

Choosing a Cryptographic Algorithm

The platform supports RSA and Elliptic Curve (EC) key pairs. Choose an algorithm based on your organisation's security requirements and compatibility needs:

Algorithm Key Sizes Recommended For
RSA 2048, 3072, 4096 bits Broad compatibility with legacy systems
Elliptic Curve P-256, P-384 (default), P-521 Modern deployments requiring smaller keys and faster operations

EC P-384 is the platform default and is recommended for most new deployments. RSA 4096 is suitable where compatibility with older systems is required.

See Supported Algorithms for the full list.

Step 1 — Create a Root Certificate Authority

  1. Navigate to Local PKI → Root Certificates in the web portal.
  2. Select Add Root Certificate, then choose Generate New.
  3. Fill in the generation form:
    • Common Name — a descriptive name for the root CA (for example, Acme Corp Root CA). Must be unique across your active root certificates.
    • Organisation — your organisation's name.
    • Organisational Unit — your department or team.
    • Country — two-letter ISO 3166-1 country code (for example, AU, NZ, US).
    • State — state or province.
    • Locality — city or locality.
    • Algorithm — select the key algorithm and size. Default is EC P-384.
    • Digest — select the signing hash algorithm. Default is SHA-256.
  4. Submit the form.

The platform dispatches the generation request to the back control plane and redirects you to a status page. Generation is asynchronous — the page polls for completion and confirms once the key pair and self-signed certificate are ready.

Root certificates are issued with a 10-year validity period.

Step 2 — Download the Root Certificate

After creation, download the root certificate so it can be distributed to your organisation's trust stores:

  1. Navigate to Local PKI → Root Certificates and open the certificate detail page.
  2. Select Download Certificate.
  3. Distribute the downloaded PEM file to the trust stores of any systems, devices, or applications that need to trust certificates issued under this root.

Once your intermediate certificates are in place (Step 4), take the root CA's private key offline. This is a PKI security best practice — with the key removed from the platform, the root CA cannot be used to issue certificates until the key is restored.

Download the Private Key

  1. Navigate to the root certificate detail page.
  2. Select Download Private Key.
  3. Save the downloaded key to a secure, offline location such as a physical HSM, encrypted offline storage, or an air-gapped system.

Delete the Private Key from the Platform

Once you have verified the key is safely stored:

  1. Navigate to the root certificate detail page.
  2. Select Delete Private Key and confirm.

Important: Deletion is permanent. Once the private key is removed from the platform, it cannot be recovered. Verify your offline backup before proceeding.

A root certificate is considered compliant by the platform once its private key has been removed, the certificate has been downloaded, and at least one active intermediate exists.

Step 4 — Create an Intermediate Certificate Authority

  1. Navigate to Local PKI → Intermediate Certificates in the web portal.
  2. Select Add Intermediate Certificate, then choose Generate New.
  3. Fill in the generation form:
    • Signing Root CA — select the root CA that will sign this intermediate from the dropdown. Only active root CAs within their validity period are selectable.
    • Common Name — a descriptive name (for example, Acme Corp Production CA).
    • Organisation, Organisational Unit, Country, State, Locality — populate as required.
    • Algorithm — select the key algorithm and size. This does not need to match the root CA's algorithm.
    • Digest — select the signing hash algorithm.
  4. Submit the form.

The platform dispatches the generation request to the back control plane, which generates the intermediate key pair and has it signed by the selected root CA. The status page polls for completion.

Intermediate certificates are issued with a 10-year validity period.

Repeat this step for each intermediate CA in your planned hierarchy.

Step 5 — Verify Your Hierarchy

After creating your root and intermediate certificates, verify the hierarchy is correctly structured:

  1. Navigate to Local PKI → Root Certificates and confirm the root certificate status is Active.
  2. Navigate to Local PKI → Intermediate Certificates and confirm each intermediate is Active and linked to its expected parent root.
  3. Review the certificate details to confirm the algorithm, validity period, and subject fields are correct before proceeding to leaf certificate issuance.

Step 6 — Distribute Trust

For your organisation's systems to trust certificates issued by your PKI, the root certificate must be added to their trust stores. How this is done depends on your environment:

  • Windows — import the root certificate into the Trusted Root Certification Authorities store via Group Policy, certutil, or the Certificates MMC snap-in.
  • Linux — place the root certificate in the system certificate directory (for example, /usr/local/share/ca-certificates/) and run update-ca-certificates.
  • macOS — import into the System Keychain using Keychain Access or the security command line tool.
  • Browsers and applications — some applications maintain their own trust stores and may require separate configuration.

Intermediate certificates do not need to be added to trust stores. They are delivered as part of the certificate chain during TLS negotiation.

Next Steps

With your PKI hierarchy in place, you are ready to begin issuing certificates:

  • Manage your certificates — view, download, and delete root and intermediate CA certificates.
  • Set up domains to control which identities your CAs can issue certificates for.
  • Configure Bridges for on-premises certificate discovery and deployment.
  • Configure Couriers for pull-based certificate delivery and CI/CD integration.
  • Define policies to enforce certificate attribute standards across your organisation.