> ## Documentation Index
> Fetch the complete documentation index at: https://infisical.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Certificate policies

> Define rules and constraints for certificates issued across your organization.

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 Infisical Certificate Management meets your organization's security and compliance requirements.

> [!NOTE]
>
> Certificate policies are created by product admins and shared across the organization. Teams consume policies through [Certificate Profiles](https://infisical.com/docs/documentation/platform/pki/settings/profiles.md).

## How policies work

When a certificate is requested, Certificate Management validates the request against the policy bound to its profile. If the request violates any policy constraint, the certificate isn't 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:

| State | Meaning | Behavior |
| - | - | - |
| **Not configured** | No constraints | Any value is allowed |
| **Configured but empty** | Explicit restriction | Nothing is allowed — all requests with this field are rejected |
| **Configured with rules** | Whitelist | Only values matching the defined rules are allowed |

> [!NOTE]
>
> 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 select **Create**.

### Policy presets

For common use cases, select a **preset** to pre-fill all the right settings:

| Preset | Use Case | Key Settings |
| - | - | - |
| **TLS Server Certificate** | Web servers, API endpoints, HTTPS | Server Auth, Digital Signature, DNS/IP SANs |
| **TLS Client Certificate** | mTLS, API authentication | Client Auth, Digital Signature, Email/DNS SANs |
| **Code Signing Certificate** | Software signing, executables | Code Signing, Digital Signature, Non-Repudiation |
| **Device Certificate** | IoT devices, embedded systems | Client Auth, Digital Signature |
| **User Certificate** | Personal authentication, smart cards | Client Auth, Email Protection |
| **Email Protection Certificate** | S/MIME, email encryption | Email Protection, Digital Signature |
| **Dual-Purpose Server Certificate** | Microservices, service mesh | Server Auth + Client Auth |
| **Intermediate CA Certificate** | Subordinate CAs | Key Cert Sign, CRL Sign, CA constraint |

> [!TIP]
>
> For most TLS use cases, start with the **TLS Server Certificate** preset. You can customize any settings after selecting a preset.

### Basic settings

| Field | Description |
| - | - |
| **Policy Name** | A slug-friendly name like `tls-server` or `internal-mtls` |
| **Description** | Optional context about this policy's purpose |
| **Certificate Validity** | Maximum lifetime for certificates (e.g., 90 days, 1 year) |

### Subject attributes

Control what X.509 distinguished name attributes can appear in certificates:

| Attribute | Abbreviation | Example |
| - | - | - |
| Common Name | CN | `api.example.com` |
| Organization | O | `Acme Corp` |
| Organizational Unit | OU | `Engineering` |
| Country | C | `US` |
| State/Province | ST | `California` |
| Locality | L | `San Francisco` |
| Domain Component | DC | `corp,example,com` |

For each attribute, configure enforcement:

> [accordion] Require
>
> Values that **must** be present. The request is rejected if the attribute is missing or doesn't match the required pattern.

> [accordion] Allow
>
> Values that are **permitted but not required**. Accepts fixed values or wildcard patterns like `*.example.com`.

> [accordion] Deny
>
> Values that **must not appear**. The request is rejected if the attribute matches a denied pattern.

> [!NOTE]
>
> Domain Component (DC) support is for requests that use DC attributes explicitly, separately from the
> Common Name. Domain components form an ordered chain in the distinguished name, so a DC rule
> constrains whole sequences rather than individual labels:
>
> * Enter the full sequence most specific component first, separated by commas. `corp,example,com`
>   describes the domain `corp.example.com`.
> * A request matches a sequence only when its components line up position by position, so the same
>   labels in another order are rejected.
> * A request's domain components are read the way the standard defines the encoding, with the
>   top-level component first, which is how Windows, Active Directory, Intune and OpenSSL all write
>   them. A CSR built with `openssl req -subj "/DC=com/DC=example/DC=corp/CN=host"` matches
>   `corp,example,com`. Writing the same subject in the reverse order describes `com.example.corp`
>   instead, and is rejected against this rule.
> * Wildcards apply within a single component. `*,example,com` matches any three-component sequence
>   ending in `example`, `com`.
> * Deny is the exception to position-by-position matching: a denied sequence is rejected wherever it
>   appears in the chain, so denying `example,com` also rejects `CN=host,DC=corp,DC=example,DC=com`.
>   Denying a domain therefore denies everything under it.
> * Add one rule per sequence you want to accept, deny, or require.

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:

| SAN Type | Example Pattern | Use Case |
| - | - | - |
| DNS | `*.example.com` | Web servers, APIs |
| IP | `10.0.0.0/8` | Internal services |
| Email | `*@example.com` | S/MIME certificates |
| URI | `spiffe://example.com/*` | SPIFFE identities |
| UPN | `*@example.com` | Active Directory user authentication |

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:

> [card] Signature Algorithms
>
> * SHA256-RSA
> * SHA384-RSA
> * SHA512-RSA
> * SHA256-ECDSA
> * SHA384-ECDSA

> [card] Key Algorithms
>
> * RSA-2048
> * RSA-4096
> * ECDSA-P256
> * ECDSA-P384
> * Ed25519

### Key usages

Define the cryptographic purposes of certificates:

| Key Usage | Purpose |
| - | - |
| Digital Signature | Sign data (TLS, code signing) |
| Key Encipherment | Encrypt symmetric keys (TLS with RSA) |
| Key Agreement | Key exchange (ECDH) |
| Certificate Sign | Sign other certificates (CA only) |
| CRL Sign | Sign certificate revocation lists (CA only) |

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:

| Extended Key Usage | Purpose |
| - | - |
| Server Authentication | TLS servers |
| Client Authentication | mTLS clients |
| Code Signing | Software artifacts |
| Email Protection | S/MIME |
| OCSP Signing | OCSP responders |
| Time Stamping | Trusted timestamps |
| Smart Card Logon | Active Directory logon, Windows Hello and other PKINIT authentication |
| Any Extended Key Usage | Any purpose |

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:

| Setting | Effect |
| - | - |
| **Forbid CA** | Certificates are end-entity only — can't sign other certificates |
| **Allow CA** | Certificates can be either CA or end-entity based on request |
| **Require CA** | All certificates must be CAs (for Root/Intermediate CA policies) |

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

### Custom extensions

Control which custom X.509 extensions certificates may carry. Each rule is one value pattern for one object identifier (OID), classified the same way subject alternative name rules are:

| Rule | Meaning |
| - | - |
| Allowed | The value may match this pattern |
| Required | The extension must be present, and its value must match one of the required patterns |
| Denied | The value must not match this pattern, even when an allowed pattern also matches it |

Add several rules for the same OID to accept more than one value. An Active Directory estate with two domains, for example, takes two Allowed rules on the security identifier extension, one wildcard per domain.

Patterns are matched against the value you enter rather than its encoded form, and matching is case sensitive. Use `*` for any value, or a wildcard such as `S-1-5-21-1004336348-1177238915-682003330-*` to accept only identifiers from one domain. A rule can also pin criticality, except where an extension's specification already fixes it.

If you configure Custom Extensions, only the OIDs you list are permitted. Any other OID in a request is rejected, including one carried in a signing request, so the patterns are what limit what an enrolling client can assert. An empty configuration forbids all custom extensions, and leaving the section unconfigured allows any OID with any value.

Infisical manages some extensions itself, so you can't set any OID under `2.5.29.` or authority information access here.

Custom extensions need a certificate authority that can emit them: an internal CA, Microsoft ADCS, or AWS Private CA. A [certificate profile](https://infisical.com/docs/documentation/platform/pki/settings/profiles.md) built on any other certificate authority can't declare them. AWS Private CA also caps a certificate at three custom extensions.

## Next steps

Once you've created a policy, combine it with a CA in a [Certificate Profile](https://infisical.com/docs/documentation/platform/pki/settings/profiles.md) that teams can consume.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.