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 a Local PKI certificate authority (backed by your own root and intermediate certificates) 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 (for domain names), your permissions, 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 for a domain name, you must have at least one active domain registered under Admin → Domains. A domain is active when it is both registered and enabled. Every domain name in the Common Name (CN) and Subject Alternative Names (SANs) must match an active registered domain. Certificate requests for unregistered or disabled domains are rejected. Public domains must also pass Domain Validation before certificates can be issued for them by ACME, Let's Encrypt, DigiCert or GlobalSign.

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.

Non-Domain Names

Certificates can also carry names that are not domain names:

Name type Example Issued as
Short hostname web01 DNS name
IP address 10.0.0.5, 2001:db8::1 IP address
URI, including SPIFFE IDs spiffe://zaita.local/ns/prod/sa/api URI
Email address [email protected] Email (rfc822Name)
MAC address aa:bb:cc:dd:ee:ff URI urn:mac:aa-bb-cc-dd-ee-ff
Phone number (leading +) +64 21 123 4567 URI tel:+64211234567

Non-domain names are not checked against registered domains, but:

  • The requesting user must have Allow non-domain certificate issuance enabled on their account (see Creating and Managing Users). Super Administrators are always allowed.
  • The certificate authority must be able to issue them. Local PKI and Microsoft ADCS certificate authorities can; ACME, Let's Encrypt, DigiCert and GlobalSign cannot, and such requests are rejected.
  • A policy using the require_domain_names rule can require domain names only for a specific certificate authority.

Certificate Providers

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

Provider Type Description
Zaita Local PKI zaita_local_pki A certificate authority you add under Integrations → Certificate Authorities, bound to one of your root certificates. It signs with an active intermediate certificate issued by that root. 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).
Let's Encrypt lets_encrypt Issues publicly trusted certificates from Let's Encrypt using CNAME-delegated DNS-01 validation.
Microsoft ADCS adcs_connector Issues certificates from an on-premises Active Directory Certificate Services CA through a Bridge.

To issue from your own PKI, create a root and an intermediate certificate, then add a Zaita Local PKI certificate authority bound to that root (see Setting Up Your PKI). You can add several, on the same or different roots. One of them is the tenant default, which is preselected in the request wizard and used when nothing else selects a certificate authority. 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 — Authority & Names Certificate provider (and signing certificate or product), then Common Name (CN) and Subject Alternative Names (SANs)
Step 1 — Subject Information Organisation, Organisational Unit, Country, State, Locality
Step 2 — Cryptographic Options Algorithm, digest, validity period, key usage
Step 3 — Review and Submit Summary of all selections before dispatch

At Step 0, you select the certificate authority first, because what names are allowed and which policies apply depend on it. 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 through the Local PKI certificate authority you select, using an active intermediate certificate under its root.

Note: The CSR upload pathway only supports Local PKI certificate authorities. 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