> ## 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 profiles

> Create reusable certificate templates that teams consume through Applications.

A certificate profile combines a [Certificate Authority](https://infisical.com/docs/documentation/platform/pki/ca/overview.md) with a [Certificate Policy](https://infisical.com/docs/documentation/platform/pki/settings/policies.md) to define how certificates are issued. Profiles are reusable templates that product admins create once and teams consume through [Applications](https://infisical.com/docs/documentation/platform/pki/applications/overview.md).

> [!NOTE]
>
> Think of a profile as the "shape" of a certificate — it defines the CA that signs it, the rules it must follow, and sensible defaults for common fields.

## Why profiles?

Profiles solve a common problem: you want consistency across certificates without requiring every team to understand PKI details.

| Without Profiles | With Profiles |
| - | - |
| Teams configure CA, policy, TTL, algorithms manually | Teams pick a profile and request certificates |
| Risk of misconfiguration | Guardrails enforced automatically |
| Duplicate setup across services | One profile used by many Applications |

## Create a certificate profile

Navigate to **Certificate Manager → Certificate Profiles** and select **Create Profile**.

### Configuration

| Field | Description |
| - | - |
| **Name** | A slug-friendly name like `web-servers` or `internal-mtls` |
| **Description** | Optional context about this profile's purpose |
| **Issuer Type** | `Certificate Authority` or `Self-Signed` |
| **Certificate Authority** | The CA that signs certificates (if Issuer Type is CA) |
| **Certificate Policy** | The policy that validates certificate requests |

> [!NOTE]
>
> If **Issuer Type** is `Self-Signed`, the profile only supports API enrollment and issues self-signed certificates.

### Profile defaults

The **Certificate Details** tab lets you pre-configure sensible defaults for certificate fields. When a requester doesn't specify a value, the profile default is applied automatically. This simplifies certificate requests — teams can issue certificates without making decisions about every field.

Defaults can be configured for:

* **TTL** (validity period)
* **Subject attributes** (CN, O, OU, C, ST, L)
* **Key algorithm** (RSA-2048, ECDSA-P256, etc.)
* **Signature algorithm**
* **Key usages** and **Extended key usages**
* **Basic constraints**

> [accordion] Combining defaults with policies
>
> For the simplest requester experience, pair defaults with a tightly scoped policy.
>
> **Example:** If your policy only allows `RSA-4096` and you set `RSA-4096` as the default, requesters never need to think about key algorithms. The profile handles it automatically.
>
> This pattern works for any field — narrow the policy to one option, set that as the default, and requesters have nothing left to decide.

> [!WARNING]
>
> If the certificate policy is updated after the profile is saved, existing defaults may no longer comply. Certificate requests will fail at validation until you update the profile defaults to match the new policy.

### Custom extensions

Set default values for custom X.509 extensions. The [certificate policy](https://infisical.com/docs/documentation/platform/pki/settings/policies.md) decides which object identifiers (OIDs) may be emitted, so a request can carry any extension the policy permits, whether or not the profile declares it. A request that supplies a signing request can carry them in the CSR, which is how an MDM enrolling over SCEP sets a per-device value.

Set a value and Infisical uses it whenever the request doesn't supply one. Leave the value empty and the request supplies it, which suits a per-principal value such as an Active Directory security identifier. Either way, Infisical checks the value against the policy's rule for that OID.

Mark an extension **Critical** when a client that can't process it must reject the certificate rather than ignore it. Leave it clear otherwise, which is the usual choice. Where an extension's own specification fixes criticality, or the certificate policy pins it for that OID, the checkbox is read only.

Enter the value as you want it read and Infisical encodes it. A few well-known extensions have a shape their specification fixes, so Infisical checks those as you type:

| Extension | Value to enter |
| - | - |
| AD SID security extension | A security identifier, such as `S-1-5-21-1004336348-1177238915-682003330-1103` |
| Certificate template name | The template name, such as `Machine` |
| Certificate template information | The template OID, a colon, then the version, such as `1.3.6.1.4.1.311.21.8.1.2:100.3` |

Any other OID takes whatever text you enter.

## How profiles are used

Profiles are consumed through [Applications](https://infisical.com/docs/documentation/platform/pki/applications/overview.md). The workflow separates responsibilities between product and application administrators:

**1. Product Admin creates a profile**

Combines a CA + policy + defaults into a reusable template that defines what certificates will look like.

**2. Product Admin creates an Application**

Creates an Application, attaches one or more profiles to it, and assigns team members (Application Admins, Operators, Auditors).

**3. Application Admin configures enrollment**

Within the Application, the Application Admin configures [enrollment methods](https://infisical.com/docs/documentation/platform/pki/applications/enrollment-methods/overview) (API, ACME, EST, SCEP) for each attached profile. The enrollment URL is unique to the Application + Profile pair.

**4. Certificates are issued**

Teams request certificates through the configured enrollment method. Requests are validated against the profile's policy and signed by the profile's CA.

This separation means:

* **Profiles are reusable** — one profile can serve many Applications
* **Enrollment is scoped** — each Application configures its own enrollment methods
* **Changes propagate** — updating a profile or policy affects all Applications using it

## FAQ

> [accordion] What's the difference between a Profile and a Policy?
>
> A **Policy** defines rules — what's allowed, what's required, what's forbidden.
>
> A **Profile** combines a policy with a CA and defaults to create a complete, consumable template.
>
> You might have one policy (`strict-tls`) used by multiple profiles (`web-servers-digicert`, `web-servers-internal`), each pointing to a different CA.

> [accordion] Can I change the CA on an existing profile?
>
> Yes, but be careful. Existing certificates remain valid (signed by the old CA), but new certificates will be signed by the new CA. Clients trusting only the old CA won't trust new certificates.

> [accordion] What happens if I delete a profile?
>
> Applications using that profile can no longer issue new certificates. Existing certificates remain valid until they expire or are revoked.

## Next steps

> [card] [Certificate Policies](https://infisical.com/docs/documentation/platform/pki/settings/policies.md)
>
> Define the rules that profiles enforce.

> [card] [Applications](https://infisical.com/docs/documentation/platform/pki/applications/overview.md)
>
> See how teams consume profiles through Applications.


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