Setting Up Certificate Policies¶

This guide walks through creating a certificate policy in the Zaita platform. For an overview of how policies work, see Certificate Policies — Introduction.

Prerequisites¶

You are signed in with the Policy Administrator or Super Administrator role.
You have identified the domains the policy should apply to and the rules you want to enforce.

Step 1 — Navigate to Policy Management¶

Navigate to Admin → Policies.
Select Create Policy.

Step 2 — Configure Basic Details¶

Field	Description
Name	A clear, descriptive name for the policy (for example, `Production TLS — Minimum Key Size` or `PCI-DSS Compliance — Public Certificates`)
Description	An explanation of why the policy exists, what compliance requirement it meets, or what it protects against. This is displayed to users when a policy violation occurs
Enabled	Whether the policy is active. Policies can be created in a disabled state for testing before activation

Tip: Use names that include the scope and intent — a name like Policy 1 provides no context when it appears in a rejection message. See Best Practices.

Step 3 — Configure Matching Criteria¶

Matching criteria determine which certificate requests this policy applies to.

Action Type¶

Select whether the policy applies to:

Option	When it applies
Certificate Issuance (`certificate.generate`)	New certificate requests
Certificate Renewal (`certificate.renew`)	Renewal of existing certificates

Most policies target issuance. Use a renewal-specific policy when you need different rules at renewal time — for example, enforcing a renewal window.

Domain Patterns¶

Add one or more domain patterns. The policy applies to any certificate request where at least one requested domain matches at least one pattern.

Pattern syntax	Example	Matches
Exact domain	`example.com`	`example.com` only
Wildcard subdomain	`*.example.com`	`example.com`, `www.example.com`, `api.example.com`
Wildcard at a deeper level	`*.prod.example.com`	`prod.example.com`, `web.prod.example.com`

Multiple patterns can be added to a single policy — for example, adding both *.internal.corp and *.staging.internal.corp to cover multiple internal scopes with a single policy.

Step 4 — Add Policy Rules¶

Rules define what the policy enforces. A policy must have at least one rule.

For each rule:

Select the Rule Type from the list of available actions.
Set the Failure Mode — Hard Fail (blocks the request) or Soft Fail (warns but allows).
Enter any required Values for the rule (for example, a minimum key size or a maximum validity period).
Add additional rules as needed.

For a complete description of every available rule type and its configuration, see the Policy Rules Reference.

Choosing Failure Modes¶

When introducing a new policy, consider starting rules as Soft Fail to observe the impact on existing certificate requests before switching to Hard Fail. This is particularly important for policies that will apply to domains with existing automation in place — a Hard Fail on an automated renewal pathway will cause the renewal to fail.

Scenario	Recommended mode
Security or compliance requirement that must be enforced	Hard Fail
Best practice guidance or recommendation	Soft Fail
New policy being phased in — monitoring period	Soft Fail initially, then Hard Fail
Rate limiting or activity monitoring	Soft Fail

Step 5 — Save and Test the Policy¶

Review the policy configuration.
Select Save.

After saving, test the policy using the Policy Validator before activating it:

Navigate to Admin → Policies → Validator.
Enter the certificate parameters you want to test against (Common Name, SANs, algorithm, validity, etc.).
Review which policies matched and what the outcome was.

Alternatively, use the Policy Test tool to test a specific policy in isolation.

Step 6 — Enable the Policy¶

If the policy was saved in a disabled state, enable it when ready:

Navigate to Admin → Policies.
Select the policy.
Select Enable.

The policy takes effect immediately for all subsequent certificate requests. In-flight requests that were already approved before the policy was enabled are not affected.

Example: Creating a Minimum Key Size Policy¶

The following example creates a policy that enforces RSA-3072 as the minimum key size for all production certificates.

Field	Value
Name	`Production — Minimum Key Size RSA-3072`
Description	`Enforces a minimum RSA key size of 3072 bits for all production certificates, in line with NIST SP 800-57 recommendations for keys protecting data through 2030.`
Action	`certificate.generate`
Domains	`*.prod.example.com`
Rule	`enforce_minimum_key_size` — Hard Fail — `minimum_bits: 3072`
Enabled	Yes

With this policy active, any certificate request for a domain matching *.prod.example.com that uses a key smaller than RSA-3072 (or its EC equivalent) will be rejected.