docs/documentation/platform/pki/settings/profiles.mdx
A certificate profile combines a Certificate Authority with a Certificate Policy to define how certificates are issued. Profiles are reusable templates that product admins create once and teams consume through Applications.
<Info> 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. </Info>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 |
Navigate to Certificate Manager → Settings → Certificate Profiles and click Create Profile.
| 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 |
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:
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. </Accordion>
<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. </Warning>Profiles are consumed through Applications. The workflow separates responsibilities between product and application administrators:
<Steps> <Step title="Product Admin creates a profile"> Combines a CA + policy + defaults into a reusable template that defines what certificates will look like. </Step> <Step title="Product Admin creates an Application"> Creates an Application, attaches one or more profiles to it, and assigns team members (Application Admins, Operators, Auditors). </Step> <Step title="Application Admin configures enrollment"> Within the Application, the Application Admin configures [enrollment methods](/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. </Step> <Step title="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. </Step> </Steps>This separation means:
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.