Skip to content

Setting Up Certificate Provisioning

This guide covers the configuration steps required before requesting certificates, and walks through each request pathway in detail. For background on how provisioning works, see Certificate Provisioning — Introduction.

Prerequisites

Register Domains

The platform requires that every Common Name (CN) and Subject Alternative Name (SAN) in a certificate request matches a domain that is both registered and enabled in your account.

  1. Navigate to Admin → Domains.
  2. Add each domain your certificates will cover. Registering an apex domain (for example, example.com) covers the domain and all its subdomains.
  3. Ensure the domain is set to active (enabled). Disabled domains are not accepted in certificate requests.

If no active domain exists, the Continue button on the Request New Certificate page is disabled until at least one domain is active. Certificate requests for unregistered or disabled domains are rejected.

Configure a Certificate Provider

Built-In Local PKI

The built-in provider is available once you have a Root Certificate and at least one active Intermediate Certificate configured under Local PKI. See Setting Up Your PKI for instructions.

An Intermediate Certificate must be in active status and within its validity period to be used for certificate signing.

External Certificate Authorities (DigiCert, GlobalSign, ACME)

External CA integrations are managed under Admin → Certificate Providers (or via the Service API at /api/v1/service/certificate-providers). Each provider must be set to active before it can be selected in a certificate request.

Provider type Required configuration
digicert api_key, organization_id
globalsign api_key, api_secret, mtls_cert, mtls_key, region, account_id
acme directory_url, account_email (optionally eab_kid and eab_hmac_key for ACME EAB)

Note: type is immutable after a provider is created. To change the type, delete the provider and create a new one.

Sensitive fields (API keys, secrets, mTLS private keys, HMAC keys) are accepted on create and update but are masked to null in all read responses to prevent credential leakage.

Requesting a Certificate — Automated Pathway

The automated pathway generates the key pair on your behalf and submits it to the chosen certificate authority.

  1. Navigate to CLM → Certificates.
  2. Select Request New Certificate.
  3. Select Automated and continue.

Step 0 — Domain Names

Field Description
Common Name The primary domain name for the certificate (for example, app.example.com). Must match a registered domain.
Subject Alternative Names Additional domain names to include (optional). Each must match a registered domain.

At least a Common Name is required. The CN is automatically included as a SAN in the generated certificate for X.509 compatibility.

The platform evaluates applicable policies against the CN and SANs at this step. If a hard-fail policy violation is found, you cannot advance until the domains are adjusted or the policy violation is resolved.

Step 1 — Subject Information

Field Description
Organisation (O) Legal name of the issuing organisation (optional).
Organisational Unit (OU) Department or team (optional).
Country (C) Two-letter ISO 3166-1 country code (optional).
State (ST) State or province (optional).
Locality (L) City or locality (optional).

Fields enforced by policy are displayed as read-only. Policy enforcement runs again when you advance from this step.

Step 2 — Cryptographic Options

Certificate Provider

Select the provider to issue this certificate. The default is Built-In (Zaita Local PKI).

Selection Additional fields
Built-In (Zaita Local PKI) Select an active Intermediate Certificate from the dropdown.
External CA (DigiCert, GlobalSign) The CA is automatically selected if only one is configured; otherwise, choose from the list. Then select a Certificate Product from the dropdown (populated from the CA's API).
ACME The ACME provider is selected; no product selection is needed.

Cryptographic settings

Field Options Default
Algorithm rsa-2048, rsa-3072, rsa-4096, ec-256, ec-384, ec-521 rsa-2048
Digest sha256, sha384, sha512 sha256
Validity (days) 1–3650 365
Key Usage Digital Signature, Non-Repudiation, Key Encipherment, Data Encipherment, Key Agreement Digital Signature + Key Encipherment
Extended Key Usage serverAuth, clientAuth, codeSigning, emailProtection, timeStamping serverAuth

Algorithm and digest fields may be locked by policy.

Step 3 — Review and Submit

Review the full request summary before submitting. The summary shows the selected provider, signing certificate or product, all subject fields, and cryptographic options.

Select Submit to dispatch the request. You are redirected to the Order status page for this request, where you can monitor progress in real time. Once complete, the certificate appears in CLM → Certificates with source: managed, and the order page provides a direct link to view or download it.

Requesting a Certificate — CSR Upload Pathway

The CSR upload pathway signs a certificate using a CSR you generate externally. This is used when you generate the key pair outside the platform — for example, on an HSM.

Note: CSR upload only supports the Built-In (Local PKI) provider.

  1. Navigate to CLM → Certificates.
  2. Select Request New Certificate.
  3. Select CSR Upload and continue.

Step 0 — Upload CSR

Paste your CSR in PEM format (beginning with -----BEGIN CERTIFICATE REQUEST-----) into the text area and select Parse.

The platform parses the CSR and extracts: - Common Name and Subject Alternative Names - Organisation, OU, Country, State, Locality - Key algorithm and size

Domain validation and policy evaluation run immediately on parse. If the CN or SANs do not match registered domains, the CSR is rejected. If a hard-fail policy violation is found, the CSR is accepted for viewing but you cannot advance.

Step 1 — Review and Configure

Verify the extracted subject information. Select:

Field Description
Signing Certificate An active Local PKI Intermediate Certificate to sign the request.
Validity (days) The validity period for the issued certificate (1–3650 days, default 90).
Digest The digest algorithm for signing (sha256, sha384, sha512).

Digest and validity may be locked or capped by policy.

Policy enforcement on CSR uploads differs from the automated pathway: since the CSR cannot be modified, enforce_values rules that require subject field values the CSR does not have will generate a policy violation rather than auto-populating the field.

Step 2 — Submit

Review the CSR details and configuration, then submit. Processing follows the same asynchronous path as automated requests. You are redirected to the Order status page after submission.

Monitoring Certificate Orders

After submitting a certificate request, you are redirected to the Order page for that request. The page updates automatically every few seconds and shows the current status.

Status Description
pending Request submitted, waiting to be picked up
processing Certificate generation is actively in progress
complete Certificate issued successfully; a link to view or download it is shown
failed Generation failed; the error message and details are displayed on the page

To view all past and in-progress orders, navigate to CLM → Certificates → Orders. You can filter by status or order type, and search by common name. Completed orders link directly to the issued certificate.

Processing time varies by provider. Local PKI requests typically complete in seconds. External CA requests (DigiCert, GlobalSign, ACME) depend on the CA's API response time and any validation steps required.

Next Steps