Certificate Policies

What is a Certificate Policy?

A Certificate Policy is a set of rules that the platform enforces automatically whenever a certificate is requested or renewed. Policies define what is and is not acceptable for certificate issuance within your organisation — covering cryptographic strength, validity periods, naming conventions, subject fields, key usage, and more.

Policies are evaluated before a certificate is issued. If a policy is violated, the request is either blocked outright or allowed through with a warning, depending on how the rule is configured.

How Policies Work

Policies are scoped to a tenant and matched to certificate requests by domain. When a certificate request is submitted — whether by a user through the web portal, via the API, or through an automated pathway — the platform:

1. Identifies the domains in the request (Common Name and Subject Alternative Names).
2. Finds all enabled policies whose domain patterns match any of those domains.
3. Evaluates every matching policy's rules against the certificate parameters.
4. Merges the results across all matching policies, keeping the most restrictive outcome per field.
5. Returns a pass or fail result.
   • If any rule is a hard fail, the request is blocked.
   • If rules produce only soft fails, the request proceeds with warnings recorded against the certificate.

This evaluation happens silently as part of certificate issuance — users do not need to take any action for policies to apply.

Matching Criteria

Each policy has a matching criteria configuration that determines when the policy applies.

Action Types

Action	When it applies
certificate.generate	New certificate issuance
certificate.renew	Certificate renewal operations

A policy can target one or both action types. It is common to have separate policies for issuance and renewal — for example, enforcing a renewal window only at renewal time.

Domain Patterns

Each policy specifies one or more domain patterns. A policy applies to a certificate request if any of the requested domains match any of the policy's patterns.

Pattern	Matches
example.com	Exactly example.com only
*.example.com	example.com and any subdomain (www.example.com, api.example.com, etc.)
*.prod.example.com	prod.example.com and any subdomain of prod

Multiple patterns can be combined in a single policy — for example, ["example.com", "*.internal.corp"] applies to either domain scope.

Failure Modes

Each rule in a policy carries a failure mode that determines what happens when the rule is violated.

Hard Fail

The certificate request is rejected. The user receives an error message identifying which policy and which rule caused the rejection. The violation is recorded in the audit log.

Use hard fail for security requirements, compliance mandates, and controls that must not be bypassed.

Soft Fail

The certificate request proceeds, but a warning is recorded against the certificate and visible in the certificate alerts view. The user sees the warning at request time. The violation is recorded in the audit log.

Use soft fail for best-practice recommendations, transitional policies being phased in, and informational monitoring rules.

Result Merging

When multiple policies match the same request, their results are merged field by field:

• If any policy produces a hard fail for a field, the field is hard-failed regardless of other results.
• A soft fail is overridden by a hard fail on the same field.
• If multiple policies fail the same field, the messages are combined.

Policy Scope

Policies are tenant-scoped. They apply only to certificate operations within the tenant they belong to and have no effect on other tenants.

Policies are evaluated regardless of which user or service account submits the request — they apply uniformly across the web portal, API, automated pathways, and ACME protocol.

Policies and Certificate Profiles

Policies also apply when configuring certificate profiles in Target Systems. When a certificate profile is created or updated, the platform evaluates all matching policies against the profile's domain names — the same way it evaluates a live certificate request.

• Fields covered by policy rules (such as algorithm, digest, key usage, or subject fields) are automatically set and locked in the profile form. A lock icon and an amber indicator mark fields that are controlled by policy. These values cannot be overridden manually.
• If a policy rule produces a hard fail against the profile's configuration, the profile cannot be saved until the configuration is adjusted to satisfy the policy.
• If a policy rule produces a soft fail, the profile can be saved but a warning is recorded against it and displayed when viewing the profile.

Policies applied to a certificate profile are shown as badge labels on the profile view and edit pages.

This behaviour ensures that certificates requested through automated target system pathways are always evaluated against the same policy rules as manually requested certificates.

Who Can Manage Policies

Policies are managed by users with the Policy Administrator or Super Administrator role. All other roles can use the policy validator and policy test tools to check how policies affect a given certificate request, but cannot create or modify policies.

See Roles and Permissions for a full description of role capabilities.

Policy Validator and Test Tools

All authenticated users have access to two policy tools:

• Policy Validator (Admin → Policies → Validator) — submit certificate parameters and see which policies apply and what the outcome would be, without issuing a certificate.
• Policy Test (Admin → Policies → Test) — run a test against a specific policy in isolation to verify its rules behave as expected.

These tools are useful for checking policy impact before deploying a new policy, or for diagnosing unexpected failures on a certificate request.