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 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: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:Basic settings
Subject attributes
Control what X.509 distinguished name attributes can appear in certificates:
For each attribute, configure enforcement:
Require
Require
Values that must be present. The request is rejected if the attribute is missing or doesn’t match the required pattern.
Allow
Allow
Values that are permitted but not required. Accepts fixed values or wildcard patterns like
*.example.com.Deny
Deny
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, 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,comdescribes the domaincorp.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"matchescorp,example,com. Writing the same subject in the reverse order describescom.example.corpinstead, and is rejected against this rule. - Wildcards apply within a single component.
*,example,commatches any three-component sequence ending inexample,com. - Deny is the exception to position-by-position matching: a denied sequence is rejected wherever it
appears in the chain, so denying
example,comalso rejectsCN=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.
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.
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:
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 built on any other certificate authority can’t declare them. AWS Private CA also caps a certificate at three custom extensions.