Skip to main content

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.

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.

​
Create a Certificate Policy

Navigate to Certificate Manager → Settings → Certificate Policies and click Create.

​
Policy Presets

For common use cases, select a preset to pre-fill all the right settings:
PresetUse CaseKey Settings
TLS Server CertificateWeb servers, API endpoints, HTTPSServer Auth, Digital Signature, DNS/IP SANs
TLS Client CertificatemTLS, API authenticationClient Auth, Digital Signature, Email/DNS SANs
Code Signing CertificateSoftware signing, executablesCode Signing, Digital Signature, Non-Repudiation
Device CertificateIoT devices, embedded systemsClient Auth, Digital Signature
User CertificatePersonal authentication, smart cardsClient Auth, Email Protection
Email Protection CertificateS/MIME, email encryptionEmail Protection, Digital Signature
Dual-Purpose Server CertificateMicroservices, service meshServer Auth + Client Auth
Intermediate CA CertificateSubordinate CAsKey Cert Sign, CRL Sign, CA constraint
For most TLS use cases, start with the TLS Server Certificate preset. You can customize any settings after selecting a preset.

​
Basic Settings

FieldDescription
Policy NameA slug-friendly name like tls-server or internal-mtls
DescriptionOptional context about this policy’s purpose
Certificate ValidityMaximum lifetime for certificates (e.g., 90 days, 1 year)

​
Subject Attributes

Control what X.509 distinguished name attributes can appear in certificates:
AttributeAbbreviationExample
Common NameCNapi.example.com
OrganizationOAcme Corp
Organizational UnitOUEngineering
CountryCUS
State/ProvinceSTCalifornia
LocalityLSan Francisco
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.
Any subject attribute in a certificate request that isn’t explicitly defined in the policy will be rejected. If no subject rules are defined, any request with subject attributes will fail.

​
Subject Alternative Names (SANs)

Control which SANs can appear on certificates:
SAN TypeExample PatternUse Case
DNS*.example.comWeb servers, APIs
IP10.0.0.0/8Internal services
Email*@example.comS/MIME certificates
URIspiffe://example.com/*SPIFFE identities
Each SAN rule specifies the type, a pattern (fixed or wildcard), and whether to allow or deny it.

​
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:
Key UsagePurpose
Digital SignatureSign data (TLS, code signing)
Key EnciphermentEncrypt symmetric keys (TLS with RSA)
Key AgreementKey exchange (ECDH)
Certificate SignSign other certificates (CA only)
CRL SignSign certificate revocation lists (CA only)

​
Extended Key Usages

Define higher-level intended uses:
Extended Key UsagePurpose
Server AuthenticationTLS servers
Client AuthenticationmTLS clients
Code SigningSoftware artifacts
Email ProtectionS/MIME
OCSP SigningOCSP responders

​
Basic Constraints

Control whether certificates can act as CAs:
SettingEffect
Forbid CACertificates are end-entity only — cannot sign other certificates
Allow CACertificates can be either CA or end-entity based on request
Require CAAll 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.

​
Next Steps

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