Skip to content

Certificate Provisioning

Certificate provisioning is the process of requesting and generating new X.509 certificates through the Zaita platform. Provisioned certificates are issued by a configured certificate authority — either the platform's built-in Local PKI or an integrated external CA — and are tracked in the centralised certificate inventory alongside any discovered certificates.

What Is Certificate Provisioning?

When you provision a certificate through Zaita, the platform:

  1. Validates your request against registered domains and any applicable policies.
  2. Generates or receives a key pair and constructs a certificate signing request (CSR).
  3. Submits the CSR to the selected certificate authority.
  4. Stores the resulting certificate in the inventory with source: managed.

Provisioned certificates are linked to the request that created them, which means they can be tracked for renewal, revoked through the platform, and monitored for upcoming expiry.

Prerequisites

Before requesting a certificate, you must have at least one active domain registered under Admin → Domains. A domain is active when it is both registered and enabled. The Common Name (CN) and all Subject Alternative Names (SANs) in a certificate request must match an active registered domain. Certificate requests for unregistered or disabled domains are rejected.

If no active domain exists, the Continue button on the Request New Certificate page is disabled and a message directs you to Admin → Domains to add or enable a domain before proceeding.

Individual users can also be restricted to specific domains. A user without permission for a domain cannot request certificates for it even if the domain is registered and active.

Certificate Providers

The platform supports multiple certificate providers. The available provider types are:

Provider Type Description
Zaita Local PKI builtin Issues certificates signed by an active Local PKI Intermediate Certificate. All cryptographic operations are handled by the Back Control Plane.
DigiCert CertCentral digicert Issues certificates through the DigiCert CertCentral API. Requires an active DigiCert integration configured under Admin.
GlobalSign Atlas globalsign Issues certificates through the GlobalSign Atlas API. Requires an active GlobalSign integration.
ACME acme Issues certificates using the ACME protocol against any compatible ACME directory (Let's Encrypt, ZeroSSL, or a custom server).

The Zaita Local PKI provider is always available once a Root and Intermediate certificate have been generated. External providers must be configured and set to active before they can be used in a certificate request.

Request Pathways

There are two ways to request a new certificate through the platform:

Automated Request

The automated request pathway guides you through a four-step wizard:

Step Content
Step 0 — Domain Names Common Name (CN) and optional Subject Alternative Names (SANs)
Step 1 — Subject Information Organisation, Organisational Unit, Country, State, Locality
Step 2 — Cryptographic Options Certificate provider, algorithm, digest, validity period, key usage
Step 3 — Review and Submit Summary of all selections before dispatch

At Step 2, you select whether to use the Built-In Local PKI or an external provider. The platform generates the key pair on your behalf and submits the request to the chosen CA.

CSR Upload

The CSR upload pathway accepts a PEM-format Certificate Signing Request that you generate externally (for example, from an HSM or hardware key store). The platform parses the CSR, validates the domains and policies, and signs the certificate using an active Local PKI Intermediate Certificate.

Note: The CSR upload pathway only supports the Built-In (Local PKI) provider. Key generation occurs outside the platform; only the signing step is performed by the Back Control Plane.

Cryptographic Options

When using the automated pathway, you select the algorithm, digest, and validity period for the certificate.

Algorithms

Value Description
rsa-2048 RSA 2048-bit
rsa-3072 RSA 3072-bit
rsa-4096 RSA 4096-bit
ec-256 ECDSA P-256
ec-384 ECDSA P-384
ec-521 ECDSA P-521

Digest Algorithms

Value Description
sha256 SHA-256 (default)
sha384 SHA-384
sha512 SHA-512

Validity

Validity is specified in days, from 1 to 3650. Common values: 90 days (3 months), 365 days (1 year), 730 days (2 years).

Key Usage

Value Description
digitalSignature Digital Signature
nonRepudiation Non-Repudiation
keyEncipherment Key Encipherment
dataEncipherment Data Encipherment
keyAgreement Key Agreement

Default: digitalSignature, keyEncipherment.

Extended Key Usage

Value Description
serverAuth TLS Web Server Authentication
clientAuth TLS Web Client Authentication
codeSigning Code Signing
emailProtection E-mail Protection
timeStamping Time Stamping

Default: serverAuth.

Policy Enforcement

Policies are evaluated against the certificate request at each step of the wizard. If any applicable policy matches the CN or SANs, the platform applies policy rules before you can proceed:

  • Enforced values — policy rules that set organisation, algorithm, digest, key usage, or validity period automatically populate the corresponding fields. Enforced fields are displayed as read-only with a lock icon.
  • Hard-fail violations — policy rules that evaluate to hard-fail block the request. You cannot proceed until the violation is resolved. A CertificateAlert of type policy_hard_fail is created.
  • Soft-fail violations — policy rules that evaluate to soft-fail allow the request to proceed but record a warning. A CertificateAlert of type policy_soft_fail is created.

Policy evaluation runs on every step transition, so changing domain names or subject information will re-evaluate applicable policies.

Asynchronous Generation

Certificate generation is dispatched as a background job and processed asynchronously. After submission, you are redirected to the order's status page, which updates in real time. Once complete, the certificate is available in the inventory under CLM → Certificates.

Certificate Orders

Every certificate request — automated wizard, CSR upload, or requests submitted by Couriers and ACME clients — is tracked as an Order. To view all orders for your account, navigate to CLM → Certificates → Orders.

The Orders page provides:

  • Status summary cards showing counts of pending, processing, complete, and failed orders
  • Search and filter by common name, order type, or status
  • A Requested By column that shows whether an order was submitted by a user, a Courier, or an ACME client

Order statuses follow this progression:

Status Description
pending Request submitted, waiting to be picked up
processing Certificate generation is actively in progress
complete Certificate issued successfully and available in the inventory
failed Certificate generation failed; error details are shown on the order detail page

Completed orders link directly to the issued certificate for quick access. Failed orders display error details to assist with troubleshooting and re-submission.

Other Provisioning Pathways

The web UI wizard is the primary way to request certificates interactively. The platform also supports additional automated provisioning pathways:

  • Target Systems — Certificate profiles attached to a Target System can trigger provisioning and renewal automatically, with certificates deployed to on-premises systems via a Bridge. Target System orders appear alongside user-initiated orders in the Orders view. See Target Systems.
  • Couriers — Automated agents (Couriers) request certificates programmatically via the REST API. Courier-initiated orders follow the same domain validation and policy rules as the web UI, and are visible in the Orders view with the Courier name as the requester. See Couriers.

Next Steps