Certificate Policy Best Practices¶

Policy Design¶

Start with Soft Fail, Then Harden¶

When introducing a new policy, configure rules as Soft Fail initially. This allows you to observe how the policy interacts with existing certificate request patterns — including automated renewal workflows — before enforcement begins.

After a monitoring period (typically one to two renewal cycles), review the soft-fail alerts in Certificates → Alerts and the audit log. Once you are confident the rules produce no unexpected failures on legitimate requests, switch the failure mode to Hard Fail.

Communicating planned policy changes to affected teams before hardening is strongly recommended.

Layer Policies by Scope¶

Organise policies into layers with increasingly specific scope rather than creating a single monolithic policy per domain:

Layer	Example	Purpose
Global	`*.example.com`	Minimum baseline — key size, algorithm, CA flag
Environment	`*.prod.example.com`	Stricter controls for production
Application	`api.prod.example.com`	Application-specific requirements
Compliance	`*.public.example.com`	Regulatory requirements (CA/B Forum, PCI-DSS)

When multiple policies match a request, results are merged with the most restrictive outcome per field. Layering allows you to define organisation-wide minimums once and extend them for specific scopes without duplicating rules.

Group rules that serve the same purpose into a single policy rather than creating one policy per rule. For example, all rules that enforce a TLS server certificate profile can live in one policy:

enforce_key_usage with serverAuth
enforce_certificate_purpose with server
block_ip_in_san
require_san
block_ca_flag

This makes policies easier to manage, audit, and understand at a glance.

Naming and Documentation¶

Use Descriptive Names and Descriptions¶

Policy names appear in rejection messages, audit log entries, and alert records. A descriptive name gives operators and users immediate context without needing to look up the policy.

Good: PCI-DSS — Minimum RSA-2048 Key Size Poor: Policy 3

The description field should explain: - Why the policy exists - Which compliance requirement or security control it addresses - What a user should do if they encounter a violation

Reference Compliance Standards Where Applicable¶

If a policy enforces a specific regulatory or industry requirement, include the standard and section in the description. For example:

Enforces a maximum validity of 398 days per CA/Browser Forum Baseline Requirements section 6.3.2. Applies to all publicly-trusted TLS certificates.

This makes it easier for auditors and team members to trace policies back to their source requirements.

Domain Matching¶

Use Wildcards for Broad Organisation-Wide Policies¶

For policies that should apply to all certificates within your organisation, use a wildcard at the top level:

*.example.com

This ensures no domain slips through without policy coverage.

Use Specific Patterns for Environment or Application Policies¶

For policies that should only apply to a subset of domains, use more specific patterns:

*.prod.example.com
*.internal.corp
api.example.com

Avoid overly broad wildcards on policies with strict Hard Fail rules unless you are certain about the coverage.

Test Domain Matching With the Policy Validator¶

Before enabling a policy, use the Policy Validator to confirm the domain patterns match the intended requests and do not match unexpected ones. Enter certificate parameters for both positive and negative cases.

Operational Safety¶

Do Not Delete Policies Used for Compliance Auditing¶

If a policy was created to meet a specific compliance requirement, retain it even if it becomes temporarily irrelevant. Deleting a policy removes the audit trail of policy enforcement from the system. Disable the policy instead if it needs to be suspended.

Disable Policies During Planned Exceptions¶

If a specific certificate request must bypass a policy for a legitimate reason — such as an emergency issuance during an incident — disable the policy temporarily rather than modifying or deleting it. Re-enable it immediately after the exception is resolved and document the exception in your change log.

Use the Renewal Window Rule for Automated Pipelines¶

If you have automated certificate renewal in place, consider adding an enforce_renewal_window rule with Soft Fail to detect and alert on renewals being triggered significantly earlier than expected. This helps identify runaway automation or misconfigured renewal schedules without blocking legitimate renewals.

Monitor After Every Policy Change¶

After creating, modifying, enabling, or disabling a policy, review the audit log and certificate alerts for at least one full renewal cycle. Policy changes can have unintended consequences on:

Automated renewal workflows run by Couriers
Certificate requests submitted via the ACME protocol
Service account API integrations

Security¶

Enforce a Minimum Baseline Across All Domains¶

At a minimum, every tenant should have a global policy covering all certificate domains that enforces:

A minimum key size (RSA-2048 or EC-256 at a minimum; RSA-3072 / EC-256 recommended)
SHA-256 minimum digest
The block_ca_flag rule, to prevent leaf certificate pathways from issuing CA-capable certificates

This baseline ensures no certificate falls below a minimum acceptable security threshold regardless of what other policies are in place.

Restrict Wildcard Certificates Unless Genuinely Required¶

Wildcard certificates increase the scope of compromise if a private key is exposed — a single compromised wildcard certificate affects every service under that domain. Use disable_wildcard with Hard Fail for domains where individual hostname certificates are operationally feasible.

Separate Policies for Issuance and Renewal¶

In some cases, different rules are appropriate at renewal vs. issuance. For example, you may want to enforce a renewal window rule (enforce_renewal_window) only at renewal time, or allow slightly longer validity for renewals during a transition period. Create separate policies with certificate.renew as the action type rather than adding renewal-specific rules to issuance policies.

Limit Policy Administrator Access¶

The Policy Administrator role has full control over the certificate policy engine. Misuse — whether accidental or deliberate — can disable all policy enforcement across the tenant. Keep this role assigned to a small number of trusted operators and review assignments regularly.