Skip to main content
A certificate policy defines the rules that certificates must follow — allowed domains, validity periods, key algorithms, and more. Policies ensure that every certificate issued through Certificate Manager meets your organization’s security and compliance requirements.
Certificate policies are created by product admins and shared across the organization. Teams consume policies through Certificate Profiles.

​
How Policies Work

When a certificate is requested, Certificate Manager validates the request against the policy bound to its profile. If the request violates any policy constraint, the certificate is not issued. This enforcement happens automatically — teams don’t need to know the policy details. They just request certificates, and the policy ensures compliance.

​
Policy Enforcement Model

Each policy field (Subject Attributes, SANs, Key Usages, etc.) follows a three-state enforcement model:
This model lets you be precise about intent. Leave a field unconfigured to allow anything, or configure it with an empty rule set to explicitly forbid it entirely.

​
Create a Certificate Policy

Navigate to Certificate Manager → Certificate Policies and click Create.

​
Policy Presets

For common use cases, select a preset to pre-fill all the right settings:
For most TLS use cases, start with the TLS Server Certificate preset. You can customize any settings after selecting a preset.

​
Basic Settings

​
Subject Attributes

Control what X.509 distinguished name attributes can appear in certificates: For each attribute, configure enforcement:
Values that must be present. The request is rejected if the attribute is missing or doesn’t match the required pattern.
Values that are permitted but not required. Accepts fixed values or wildcard patterns like *.example.com.
Values that must not appear. The request is rejected if the attribute matches a denied pattern.
Domain Component (DC) support is for requests that use DC attributes explicitly. Each DC value is matched independently against the Domain Component rule (like a Subject Alternative Name), separately from the Common Name. A subject can carry more than one domain component (for example CN=host, DC=auth, DC=example, DC=app), so allow the labels your requests use, such as auth, example, and app, or a pattern like *.
Once you define subject attribute rules, only the attribute types you explicitly include are permitted — any other attribute in a request will be rejected. An empty configuration forbids all subject attributes; leave the section unconfigured to allow any attribute.

​
Subject Alternative Names (SANs)

Control which SANs can appear on certificates: Each SAN rule specifies the type, a pattern (fixed or wildcard), and whether to allow or deny it. Once you define SAN rules, only the SAN types you explicitly include are permitted — any other SAN type in a request will be rejected. An empty SAN configuration forbids all SANs; leave the section unconfigured to allow any SAN type.

​
Key & Signature Algorithms

Restrict which cryptographic algorithms are permitted:

Signature Algorithms

  • SHA256-RSA
  • SHA384-RSA
  • SHA512-RSA
  • SHA256-ECDSA
  • SHA384-ECDSA

Key Algorithms

  • RSA-2048
  • RSA-4096
  • ECDSA-P256
  • ECDSA-P384
  • Ed25519

​
Key Usages

Define the cryptographic purposes of certificates: If you configure Key Usages, only the usages listed in Required or Allowed are permitted. Leave Key Usages unconfigured to allow any key usage.

​
Extended Key Usages

Define higher-level intended uses: If you configure Extended Key Usages, only the usages listed in Required or Allowed are permitted. Leave Extended Key Usages unconfigured to allow any extended key usage.

​
Basic Constraints

Control whether certificates can act as CAs: Maximum Path Length: Limits how many intermediate CAs can exist below this certificate. 0 means the CA can only sign end-entity certificates.

​
Next Steps

Once you’ve created a policy, combine it with a CA in a Certificate Profile that teams can consume.