Certificate profile and template governance
Trust Architecture Playbook: Governance pillar
Profile catalog baseline
A certificate profile is where governance becomes enforceable. Certificate profiles define the issuing CA, enrollment method, authentication method, business unit, certificate properties, and cryptographic settings for all certificates enrolled through DigiCert® Trust Lifecycle Manager. Use this section as the canonical profile standard for the rest of the pillar. Other sections should identify the approved profile, profile owner, CA source, business unit, and exception status; they should not recreate local profile rules unless a new governance decision is required.
Profile catalog design should be boring by intention. The goal is the minimum number of profiles that cover approved use cases while preserving separation by environment, trust type, issuing CA, enrollment/authentication method, certificate type, and risk tier. A catalog with hundreds of near-duplicate profiles is not flexible governance; it is control drift.
When designing the profile catalog:
Require a named profile owner and policy owner for every profile.
Separate production from non-production profiles.
Separate public trust from private trust profiles.
Separate server authentication, client authentication, mTLS, user, device, and special-purpose profiles.
Avoid broad SAN and wildcard permissions unless explicitly approved and blast radius is documented.
Bind profiles to approved CA sources and business units only.
Define certificate metadata and owners at the profile level where appropriate.
Review profile usage and retire profiles that are unused, duplicative, too broad, or no longer mapped to an active business need.
Wichtig
Key takeaway
The profile catalog is the most important day-to-day governance artifact in Trust Lifecycle Manager. If the profile is wrong, every correct automation step enforces the wrong policy faster.
Minimum profile elements
Profile element | Governance requirement |
|---|---|
Must align to the correct organizational, platform, application, or trust-domain control boundary. | |
Must be approved in the CA source registry for the certificate type and environment. | |
Must match the allowed request path: web-based (Browser PKCS12 or CSR), enrollment protocols (SCEP, EST, or CMP), managed automation (Admin web request, agent, or sensor), ACME, REST API, DigiCert Trust Assistant, Microsoft Autoenrollment, or other approved method. | |
Must prove the requester, system, user, device, workload, or delegated authority is entitled to use the profile. | |
Must specify approved algorithms, key type and sizes. | |
Must align to public-trust requirements where applicable and to operational renewal capability for private trust. | |
Must control whether fields accept single or multiple values, and constrain their source. | |
Must constrain use to intended purpose. Server auth, client auth, mTLS, user, and device profiles should be distinct. | |
Must attach owners, tags, and custom attributes needed for identification, audit, and triage. |
Profile intake workflow
New profiles should not be created on demand. The intake workflow forces a deliberate decision about whether a new profile is genuinely needed, and assigns ownership and review criteria before it goes live.
Requester identifies the use case, trust domain, environment, platform, relying-party population, and required enrollment method.
PKI/security confirms whether an existing profile can satisfy the request without weakening policy.
If a new profile is required, the requester documents the CA source, business unit, enrollment/authentication methods, certificate properties, validity, owner model, and evidence requirements.
The profile owner and policy authority review blast radius, delegated scope, automation readiness, and exception implications.
Governance approves, rejects, or routes the request to remediation. Approved profiles receive an owner, review date, and retirement criteria.
The profile is tested in non-production where applicable and monitored for unexpected issuance patterns after go-live.
Profile usage is reviewed on cadence and retired or tightened when observed use no longer matches the approved intent.
Example profile intake request
A profile intake request should force the requester to explain the control boundary, not merely ask for a new template. The following example is intentionally narrow so the approved profile does not become a general-purpose issuance path.
Intake field | Example request |
|---|---|
Requested profile name | Public TLS / production web / ACME. |
Business unit | Customer portal engineering. |
Trust domain | Public TLS - corporate domains. |
CA source | Approved public TLS CA source in the CA source registry. |
Environment and tier | Production; Tier 1. |
Certificate type and EKUs | Server authentication only. |
Subject/SAN settings | Allow multiple SANs; wildcard not requested. |
Enrollment and authentication method | ACME using a dedicated service user and approved DNS validation control. |
Owner model | Named service owner, platform owner, and certificate owner assigned before go-live. |
Evidence requirement | Profile approval, domain authorization, issuance event, deployment validation, CT log reconciliation, and owner notification. |
Governance disposition | Approved for controlled pilot; review profile usage, SAN patterns, and exception volume after 60 days. |