Certificate Profiles - CLI Reference

Overview

Certificate profiles are templates that define the structure, content, and constraints of X.509 certificates issued by FreeIPA’s Certificate Authority. Profiles act as policy documents that control every aspect of a certificate: its validity period, permitted key usages, subject alternative names, certificate extensions, and validation rules for certificate requests.

When a certificate is requested, the CA uses the specified profile to:

Validate the request: Check if the Certificate Signing Request (CSR) meets profile requirements (key size, signature algorithm, requested extensions)
Populate certificate fields: Set subject DN components, validity period, serial number
Add extensions: Include X.509 extensions like Key Usage, Extended Key Usage, Subject Alternative Name, CRL Distribution Points
Apply constraints: Enforce organizational policies (maximum validity, allowed key types, extension restrictions)

Certificate profiles enable organizations to implement diverse certificate use cases with consistent policies:

User certificates: For email encryption, client authentication, smart card login Service certificates: For TLS/SSL servers (HTTPS, LDAP, SMTP) Host certificates: For system authentication and enrollment Code signing certificates: For software package signing VPN certificates: For IPsec or OpenVPN authentication

FreeIPA includes several built-in profiles for common scenarios and supports importing custom profiles for specialized requirements.

Profile Architecture

Dogtag Integration

FreeIPA’s PKI is powered by Dogtag Certificate System (also known as Red Hat Certificate System). Certificate profiles are Dogtag configuration objects stored in the Dogtag CA subsystem and referenced by IPA.

Profile format: Dogtag property-list format (plain text key-value pairs) Profile storage: Dogtag CA configuration directory and IPA LDAP Profile execution: Dogtag CA engine processes profiles during certificate issuance Profile constraints: IPA enforces additional restrictions on profile configuration for security and compatibility

Profile Components

A certificate profile consists of several interconnected components:

Inputs: Define what information must be provided in the certificate request (subject DN components, key type, requested extensions)

Outputs: Define what information is returned after certificate issuance (certificate, certificate chain, PKCS#7 format)

Policy Sets: Collections of policy rules that validate requests and populate certificate fields

Constraints: Rules that reject requests not meeting criteria (key size, signature algorithm, subject DN format)

Defaults: Values automatically populated in certificates when not provided in the request

Profile ID

Profile IDs are identifiers used to reference profiles in commands and CA ACLs:

Format: Start with letter, followed by letters, digits, or underscore (_) Case-sensitive: caIPAserviceCert differs from caipaservicecert No spaces or punctuation: Underscores permitted, hyphens not Examples: caIPAserviceCert, IECUserRoles, caJavaAppletCert, MyCustomProfile

Built-in Profiles

FreeIPA includes several profiles for common use cases:

caIPAserviceCert

Purpose: Service and host certificates for TLS/SSL servers Subject: Service or host principal (e.g., HTTP/web1.example.com) Key Usage: Digital Signature, Key Encipherment Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication Validity: 2 years (default) Common uses: HTTPS servers, LDAP servers, SMTP TLS, database servers

caIPAuserCert

Purpose: User certificates for authentication and encryption Subject: User principal (e.g., alice@EXAMPLE.COM) Key Usage: Digital Signature, Key Encipherment Extended Key Usage: TLS Web Client Authentication, Email Protection Validity: 2 years (default) Common uses: Smart card login, email S/MIME, client authentication

IECUserRoles

Purpose: User certificates with role extensions Subject: User principal Key Usage: Digital Signature, Non-Repudiation, Key Encipherment Extended Key Usage: TLS Web Client Authentication, Email Protection Special: Includes IEC 62351-8 role extension for industrial control systems Common uses: SCADA systems, industrial networks, role-based access

KDCs_PKINIT_Certs

Purpose: KDC certificates for PKINIT (Kerberos using public key) Subject: KDC service principal Key Usage: Digital Signature, Key Encipherment Extended Key Usage: KDC Authentication Common uses: Kerberos PKINIT, smart card authentication to Kerberos

caIPAkraCert

Purpose: Key Recovery Authority (KRA) certificates Subject: KRA service principal Key Usage: Digital Signature, Key Encipherment, Data Encipherment Common uses: Internal IPA KRA service certificates

Profile Configuration Format

Property-List Syntax

Profiles use Dogtag’s property-list format (not XML):

profileId=MyCustomProfile
classId=caEnrollImpl
desc=My Custom Certificate Profile
enable=true
auth.instance_id=raCertAuth

input.list=i1
input.i1.class_id=certReqInputImpl

output.list=o1
output.o1.class_id=certOutputImpl

policyset.list=serverCertSet
policyset.serverCertSet.list=1,2,3,4

policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl
policyset.serverCertSet.1.constraint.name=Subject Name Constraint
policyset.serverCertSet.1.constraint.params.pattern=CN=.*
policyset.serverCertSet.1.default.class_id=userSubjectNameDefaultImpl
policyset.serverCertSet.1.default.name=Subject Name Default

Key-value pairs: key=value format, one per line Sections: Grouped by prefixes (input, output, policyset) Lists: Comma-separated (e.g., policyset.list=serverCertSet) Hierarchy: Dot notation for nested properties (e.g., policyset.serverCertSet.1.constraint.class_id)

Required Fields

IPA enforces specific requirements for profile compatibility:

profileId: Must match the Profile ID given in certprofile-import command classId: Must be caEnrollImpl (certificate enrollment profile) auth.instance_id: Must be raCertAuth (IPA RA authentication) input.*.class_id: Must use certReqInputImpl output.*.class_id: Must use certOutputImpl

These restrictions ensure profiles integrate correctly with IPA’s enrollment workflow and security model.

Common Profile Settings

Validity period: Controlled by policyset.*.*.default.params.range (in days)

policyset.serverCertSet.3.default.params.range=730
# 730 days = 2 years

Key Usage: Digital Signature, Non-Repudiation, Key Encipherment, Data Encipherment, Key Agreement, Certificate Sign, CRL Sign, Encipher Only, Decipher Only

policyset.serverCertSet.5.default.params.keyUsageDigitalSignature=true
policyset.serverCertSet.5.default.params.keyUsageKeyEncipherment=true

Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication, Code Signing, Email Protection, Time Stamping, OCSP Signing

policyset.serverCertSet.6.default.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2
# 1.3.6.1.5.5.7.3.1 = TLS Web Server Authentication
# 1.3.6.1.5.5.7.3.2 = TLS Web Client Authentication

Subject DN pattern: Constraint on subject distinguished name

policyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,O=EXAMPLE.COM

Key algorithm: RSA, EC (elliptic curve), DSA

Key size: Minimum key length constraint

policyset.serverCertSet.4.constraint.params.keyType=RSA
policyset.serverCertSet.4.constraint.params.keyParameters=2048,3072,4096

Certificate Storage

The --store parameter controls whether issued certificates are stored in IPA’s LDAP database:

--store=true (default): Certificates are stored in LDAP and retrievable via ipa cert-show

Enables certificate lifecycle management (tracking, renewal, revocation)
Required for IPA-managed service and host certificates
Certificates consume LDAP storage

--store=false: Certificates are issued but not stored in LDAP

Useful for short-lived certificates (ephemeral containers, temporary credentials)
Reduces LDAP storage overhead for high-volume issuance
Certificates cannot be retrieved after issuance; requester must save them
Revocation still works (CRL entries created based on serial number)

Use --store=false for:

Short-lived certificates (hours or days)
High-volume issuance scenarios (thousands of certificates)
Certificates that will be replaced frequently (DevOps automation)

Use --store=true for:

Long-lived certificates (months or years)
Certificates requiring renewal tracking
Certificates with compliance/audit requirements

Examples

List All Certificate Profiles

# View all available profiles
$ ipa certprofile-find
  5 profiles matched
  Profile ID: caIPAserviceCert
  Description: Standard profile for network services
  Store issued certificates: TRUE
  Profile ID: caIPAuserCert
  Description: Standard profile for user certificates
  Store issued certificates: TRUE
  Profile ID: IECUserRoles
  Description: User Certificate with IEC 62351-8 Role Extension
  Store issued certificates: TRUE
  [...]

Show Profile Details

# View specific profile configuration
$ ipa certprofile-show caIPAserviceCert
  Profile ID: caIPAserviceCert
  Profile description: Standard profile for network services
  Store issued certificates: TRUE

Export Profile Configuration

# Save profile to file for editing
$ ipa certprofile-show caIPAserviceCert --out caIPAserviceCert.cfg

# View the exported configuration
$ cat caIPAserviceCert.cfg
  profileId=caIPAserviceCert
  classId=caEnrollImpl
  desc=Standard profile for network services
  [... full profile configuration ...]

Import Custom Profile

# Create custom profile based on existing profile
$ ipa certprofile-show caIPAserviceCert --out MyCustom.cfg

# Edit MyCustom.cfg to modify settings
# Change profileId, adjust validity, modify extensions

$ ipa certprofile-import MyCustomProfile \
  --file=MyCustom.cfg \
  --desc="Custom profile for application services" \
  --store=true

  Profile ID: MyCustomProfile
  Profile description: Custom profile for application services
  Store issued certificates: TRUE

Import Short-Lived Certificate Profile

# Import profile for ephemeral certificates (not stored)
$ ipa certprofile-import ShortLivedCert \
  --file=ShortLived.cfg \
  --desc="Short-lived certificates for containers" \
  --store=false

  Profile ID: ShortLivedCert
  Profile description: Short-lived certificates for containers
  Store issued certificates: FALSE

Modify Profile Description

# Update profile description
$ ipa certprofile-mod MyCustomProfile \
  --desc="Updated description for custom profile"

Modify Profile Configuration

# Edit profile configuration file
$ ipa certprofile-show MyCustomProfile --out MyCustom.cfg
$ vi MyCustom.cfg  # Edit validity, extensions, constraints

# Import updated configuration
$ ipa certprofile-mod MyCustomProfile --file=MyCustom.cfg

  Modified profile "MyCustomProfile"

Change Certificate Storage Policy

# Disable storage for existing profile
$ ipa certprofile-mod MyCustomProfile --store=false

  Profile ID: MyCustomProfile
  Store issued certificates: FALSE

Delete Custom Profile

# Remove custom profile (built-in profiles cannot be deleted)
$ ipa certprofile-del MyCustomProfile
  Deleted profile "MyCustomProfile"

Search Profiles by Storage Policy

# Find profiles that store certificates
$ ipa certprofile-find --store=true

# Find profiles that don't store certificates
$ ipa certprofile-find --store=false

Search Profiles by Name Pattern

# Find service-related profiles
$ ipa certprofile-find --id=*service*

# Find user-related profiles
$ ipa certprofile-find --id=*user*

Create Code Signing Profile

# Export base profile
$ ipa certprofile-show caIPAserviceCert --out CodeSigning.cfg

# Edit CodeSigning.cfg:
# - Change profileId to CodeSigningCert
# - Set Extended Key Usage to Code Signing (1.3.6.1.5.5.7.3.3)
# - Adjust validity to 1 year (365 days)
# - Add code signing constraints

# Import code signing profile
$ ipa certprofile-import CodeSigningCert \
  --file=CodeSigning.cfg \
  --desc="Code signing certificates for build engineers" \
  --store=true

Create VPN Certificate Profile

# Create VPN-specific profile with IPsec extended key usage
$ ipa certprofile-import VPNCert \
  --file=VPN.cfg \
  --desc="VPN certificates for remote access" \
  --store=true

# VPN.cfg includes:
# Extended Key Usage: 1.3.6.1.5.5.7.3.2 (TLS Client Auth)
# Extended Key Usage: 1.3.6.1.5.5.7.3.1 (TLS Server Auth) for VPN gateways

Create Email Certificate Profile

# Create S/MIME email certificate profile
$ ipa certprofile-import EmailCert \
  --file=Email.cfg \
  --desc="S/MIME email certificates" \
  --store=true

# Email.cfg includes:
# Extended Key Usage: 1.3.6.1.5.5.7.3.4 (Email Protection)
# Subject Alternative Name: email address

Create Device Certificate Profile

# Create IoT device certificate profile
$ ipa certprofile-import IoTDeviceCert \
  --file=IoTDevice.cfg \
  --desc="IoT device certificates" \
  --store=false  # Devices may be ephemeral

# IoTDevice.cfg includes:
# Short validity: 90 days
# Extended Key Usage: TLS Client Authentication

Test Profile Before Production

# Import test profile
$ ipa certprofile-import TestProfile \
  --file=Test.cfg \
  --desc="TEST - Do not use in production" \
  --store=false

# Request test certificate
$ ipa cert-request test.csr \
  --principal=test/test.example.com \
  --profile-id=TestProfile

# Verify certificate meets requirements
# Delete test profile when testing complete
$ ipa certprofile-del TestProfile

Clone Existing Profile

# Export existing profile as template
$ ipa certprofile-show caIPAserviceCert --out ServiceCert-v2.cfg

# Edit ServiceCert-v2.cfg
# Change profileId to caIPAserviceCert-v2
# Modify validity, add custom extensions

# Import as new profile
$ ipa certprofile-import caIPAserviceCert-v2 \
  --file=ServiceCert-v2.cfg \
  --desc="Service certificate profile v2 with extended validity"

Best Practices

Profile Design

Purpose-specific profiles: Create dedicated profiles for different use cases (web servers, email, VPN, code signing) rather than one “universal” profile. This enables precise policy enforcement.

Descriptive IDs: Use clear profile IDs that indicate purpose: WebServerCert, EmailSMIME, VPNClient rather than CustomProfile1.

Document profiles: Maintain external documentation explaining each profile’s purpose, constraints, validity period, and intended use cases.

Validity periods: Match validity to use case. Web servers: 1-2 years. Code signing: 1-3 years. Ephemeral containers: hours-days. Users: 1-2 years.

Extension selection: Only include extensions actually needed. Excessive extensions increase certificate size and processing overhead.

Security Considerations

Key constraints: Enforce minimum key sizes in profile constraints (RSA ≥2048 bits, EC ≥256 bits). Reject weak keys.

Subject DN validation: Use subject DN pattern constraints to enforce organizational naming standards and prevent impersonation.

Extended Key Usage: Always specify Extended Key Usage. Without it, certificates can be used for unintended purposes (server cert used for email signing).

Critical extensions: Mark security-relevant extensions as critical (Key Usage, Extended Key Usage, Basic Constraints). Clients must reject certificates with unrecognized critical extensions.

Validity limits: Enforce maximum validity periods in profiles. Many compliance frameworks limit certificate validity (e.g., public CAs limited to 398 days).

Store=false carefully: Only use --store=false for truly ephemeral certificates. Non-stored certificates cannot be centrally tracked or audited.

Operational Practices

Version profiles: When significantly changing a profile, create a new profile ID (e.g., MyProfile-v2) rather than modifying the existing one. This enables gradual migration and rollback.

Test before production: Import and test new profiles in non-production environments first. Request test certificates and verify they meet requirements.

CA ACL integration: After importing a profile, create CA ACL rules defining who can use it. Unrestricted profiles defeat access control.

Profile lifecycle: Maintain profiles through their lifecycle: development → testing → production → deprecation → deletion.

Change management: Treat profile changes as infrastructure changes requiring approval, documentation, and communication.

Backup profiles: Export profile configurations and store in version control. This enables disaster recovery and change tracking.

Profile Maintenance

Regular review: Periodically audit profiles to ensure they still meet security and business requirements. Remove obsolete profiles.

Compliance alignment: Ensure profiles comply with organizational security policies and industry standards (e.g., CA/Browser Forum Baseline Requirements for public CAs).

Extension updates: Monitor X.509 standards evolution. New extensions or deprecated extensions may require profile updates.

Coordinate with CA ACLs: Profile changes may require CA ACL updates to grant or restrict access appropriately.

Integration Points

Certificate Authorities

Profiles are executed by CAs during certificate issuance:

Profile-CA relationship: Profiles can be used with any CA (root or subordinate) unless restricted by CA ACLs CA selection: Certificate requests specify both profile ID and CA name CA ACL enforcement: CA ACLs control which principals can use which profiles with which CAs

Commands: ca-find, ca-show, caacl-add-profile

CA ACLs

CA ACLs reference profiles to control certificate issuance:

Profile scope: CA ACLs include profile IDs to restrict which profiles can be used Access control: Principals can only request certificates using profiles permitted by CA ACLs Default deny: Without CA ACL granting access, profiles cannot be used

Commands: caacl-add-profile, caacl-remove-profile

Certificate Requests

Certificate requests specify which profile to use:

Profile selection: cert-request --profile-id=<ProfileID> Validation: Dogtag validates CSR against profile constraints Population: Dogtag populates certificate fields using profile defaults and policies

Commands: cert-request, cert-show

Dogtag Certificate System

Profiles are Dogtag configuration objects:

Profile storage: Profiles stored in Dogtag CA’s CS.cfg and profile directory Profile execution: Dogtag CA engine interprets profile configuration during issuance Profile updates: Changes to profiles require Dogtag CA restart in some versions

RBAC

Profile management requires appropriate permissions:

“System: Import Certificate Profile”: Required to import new profiles “System: Modify Certificate Profile”: Required to modify profiles “System: Delete Certificate Profile”: Required to delete profiles “System: Read Certificate Profiles”: Required to view profiles

These permissions typically granted via “Certificate Administrator” role.

Replication

Profile configuration replicates across IPA servers:

IPA LDAP replication: Profile metadata (ID, description, store flag) replicates via LDAP Dogtag replication: Profile files replicate to all CA-enabled replicas Consistency: Changes may take minutes to propagate in multi-master environments

Commands

certprofile-del

Usage: ipa [global-options] certprofile-del ID [options]

Delete a Certificate Profile.

Arguments

Argument	Required	Description
`ID`	yes	Profile ID for referring to this profile

Options

Option	Description
`--continue`	Continuous mode: Don’t stop on errors.

certprofile-find

Usage: ipa [global-options] certprofile-find [CRITERIA] [options]

Search for Certificate Profiles.

Arguments

Argument Required Description

CRITERIA no A string searched in all relevant object attributes

Options

Option	Description
`--id ID`	Profile ID for referring to this profile
`--desc DESC`	Brief description of this profile
`--store STORE`	Whether to store certs issued using this profile
`--timelimit TIMELIMIT`	Time limit of search in seconds (0 is unlimited)
`--sizelimit SIZELIMIT`	Maximum number of entries returned (0 is unlimited)
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.
`--pkey-only`	Results should contain primary key attribute only (“id”)

certprofile-import

Usage: ipa [global-options] certprofile-import ID [options]

Import a Certificate Profile.

Arguments

Argument	Required	Description
`ID`	yes	Profile ID for referring to this profile

Options

Option	Description
`--desc DESC`	Brief description of this profile
`--store STORE`	Whether to store certs issued using this profile
`--file FILE`	Filename of a raw profile. The XML format is not supported.
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.

certprofile-mod

Usage: ipa [global-options] certprofile-mod ID [options]

Modify Certificate Profile configuration.

Arguments

Argument	Required	Description
`ID`	yes	Profile ID for referring to this profile

Options

Option	Description
`--desc DESC`	Brief description of this profile
`--store STORE`	Whether to store certs issued using this profile
`--setattr SETATTR`	Set an attribute to a name/value pair. Format is attr=value.
`--addattr ADDATTR`	Add an attribute/value pair. Format is attr=value. The attribute
`--delattr DELATTR`	Delete an attribute/value pair. The option will be evaluated
`--rights`	Display the access rights of this entry (requires —all). See ipa man page for details.
`--file FILE`	File containing profile configuration
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.

certprofile-show

Usage: ipa [global-options] certprofile-show ID [options]

Display the properties of a Certificate Profile.

Arguments

Argument	Required	Description
`ID`	yes	Profile ID for referring to this profile

Options

Option	Description
`--rights`	Display the access rights of this entry (requires —all). See ipa man page for details.
`--out OUT`	Write profile configuration to file
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.

Use Cases

Creating Custom Web Server Certificate Profile with Extended Validity

Organizations requiring longer certificate validity than default profiles can create custom profiles with extended validity periods while maintaining appropriate security controls.

# Export existing caIPAserviceCert profile as template
ipa certprofile-show caIPAserviceCert --out=/tmp/base-profile.cfg

# Edit /tmp/base-profile.cfg to modify:
# - policyset.serverCertSet.5.default.params.range=730 (2 years)
# - desc=Extended Validity Web Server Certificates
# - profileId=ExtendedWebServerCert

# Import custom profile
ipa certprofile-import ExtendedWebServerCert \
  --file=/tmp/extended-web-profile.cfg \
  --desc="Web server certificates with 2-year validity" \
  --store=true

# Enable the profile
ipa certprofile-mod ExtendedWebServerCert --enable

# Create CA ACL to control access
ipa caacl-add extended_web_certs
ipa caacl-add-profile extended_web_certs --certprofiles=ExtendedWebServerCert
ipa caacl-add-host extended_web_certs --hostgroups=web-servers
ipa caacl-add-ca extended_web_certs --cas=ipa
ipa caacl-enable extended_web_certs

Code Signing Certificate Profile with Restricted Key Usage

Code signing certificates require specific X.509 extensions and key usage restrictions to ensure they can only be used for code signing purposes and not for other operations like TLS.

# Create code signing profile based on existing profile
ipa certprofile-show caIPAserviceCert --out=/tmp/code-signing-base.cfg

# Modify /tmp/code-signing.cfg to include:
# - policyset.codeSignSet.1.default.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.3 (code signing)
# - policyset.codeSignSet.2.default.params.keyUsage=digitalSignature (only)
# - Remove serverAuth and clientAuth extended key usages
# - Set profileId=CodeSigningCert

ipa certprofile-import CodeSigningCert \
  --file=/tmp/code-signing.cfg \
  --desc="Code signing certificates for software packages" \
  --store=true

ipa certprofile-mod CodeSigningCert --enable

# Restrict to build systems only
ipa caacl-add code_signing_certs
ipa caacl-add-profile code_signing_certs --certprofiles=CodeSigningCert
ipa caacl-add-host code_signing_certs --hosts=build01.example.com
ipa caacl-add-ca code_signing_certs --cas=ipa
ipa caacl-enable code_signing_certs

Email Certificate Profile with S/MIME Extensions

Email encryption and signing requires certificates with specific S/MIME capabilities and email address subject alternative names.

# Export user certificate profile as base
ipa certprofile-show IPA.USER.CERT --out=/tmp/email-base.cfg

# Create email profile with modifications:
# - Add emailProtection extended key usage (1.3.6.1.5.5.7.3.4)
# - Configure SAN email input
# - Set emailAddress in subject DN
# - profileId=EmailCert

ipa certprofile-import EmailCert \
  --file=/tmp/email-cert.cfg \
  --desc="S/MIME certificates for email encryption and signing" \
  --store=true

ipa certprofile-mod EmailCert --enable

# Allow all users to request email certificates
ipa caacl-add email_certificates
ipa caacl-add-profile email_certificates --certprofiles=EmailCert
ipa caacl-mod email_certificates --usercat=all
ipa caacl-add-ca email_certificates --cas=ipa
ipa caacl-enable email_certificates

Short-Lived Certificate Profile for Temporary Access

Temporary workers or short-term projects require certificates with very short validity periods that automatically expire, reducing revocation overhead.

# Create short-lived profile
ipa certprofile-show caIPAserviceCert --out=/tmp/short-lived-base.cfg

# Modify for short validity:
# - policyset.serverCertSet.5.default.params.range=7 (7 days)
# - policyset.serverCertSet.5.constraint.params.range=7
# - profileId=ShortLivedCert

ipa certprofile-import ShortLivedCert \
  --file=/tmp/short-lived.cfg \
  --desc="7-day validity certificates for temporary access" \
  --store=true

ipa certprofile-mod ShortLivedCert --enable

# Associate with temporary user group
ipa caacl-add temp_worker_certs
ipa caacl-add-profile temp_worker_certs --certprofiles=ShortLivedCert
ipa caacl-add-user temp_worker_certs --groups=contractors
ipa caacl-add-ca temp_worker_certs --cas=ipa
ipa caacl-enable temp_worker_certs

Subordinate CA Certificate Profile for PKI Hierarchy

Organizations building multi-level PKI hierarchies need profiles capable of issuing CA certificates with proper basicConstraints and pathLength settings.

# Note: Creating CA certificate profiles requires careful Dogtag configuration
# This example shows the IPA integration portion

# Export CA signing profile (if available)
# Custom Dogtag CA profile must be created first with:
# - basicConstraints CA:TRUE, pathLen:0 for intermediate CA
# - keyUsage keyCertSign, cRLSign
# - Create profile in Dogtag: pki-server ca-profile-add SubCAProfile

# Import to IPA once created in Dogtag
ipa certprofile-import SubordinateCA \
  --file=/tmp/sub-ca-profile.cfg \
  --desc="Subordinate CA certificates for PKI hierarchy" \
  --store=true

ipa certprofile-mod SubordinateCA --enable

# Highly restricted access
ipa caacl-add sub_ca_issuance
ipa caacl-add-profile sub_ca_issuance --certprofiles=SubordinateCA
ipa caacl-add-user sub_ca_issuance --users=pki-admin
ipa caacl-add-ca sub_ca_issuance --cas=ipa
ipa caacl-enable sub_ca_issuance

Client Authentication Certificate with No Server Auth

VPN or wireless authentication requires client authentication certificates that cannot be misused for server authentication to prevent impersonation attacks.

# Create client-only authentication profile
ipa certprofile-show caIPAserviceCert --out=/tmp/client-only-base.cfg

# Modify profile:
# - Extended Key Usage: clientAuth only (1.3.6.1.5.5.7.3.2)
# - Remove serverAuth (1.3.6.1.5.5.7.3.1)
# - Key Usage: digitalSignature, keyAgreement
# - profileId=ClientAuthCert

ipa certprofile-import ClientAuthCert \
  --file=/tmp/client-auth.cfg \
  --desc="Client authentication only certificates for VPN/wireless" \
  --store=true

ipa certprofile-mod ClientAuthCert --enable

# Associate with VPN users
ipa caacl-add vpn_client_certs
ipa caacl-add-profile vpn_client_certs --certprofiles=ClientAuthCert
ipa caacl-add-user vpn_client_certs --groups=vpn-users
ipa caacl-add-ca vpn_client_certs --cas=ipa
ipa caacl-enable vpn_client_certs

OCSP Signing Certificate Profile for Revocation Services

OCSP responders require special certificates with OCSP signing extended key usage and appropriate validity periods for certificate status checking.

# Create OCSP signing profile
# Base this on service cert profile
ipa certprofile-show caIPAserviceCert --out=/tmp/ocsp-base.cfg

# Modify for OCSP:
# - Extended Key Usage: OCSPSigning (1.3.6.1.5.5.7.3.9)
# - Key Usage: digitalSignature, nonRepudiation
# - Add OCSPNoCheck extension
# - profileId=OCSPSigningCert

ipa certprofile-import OCSPSigningCert \
  --file=/tmp/ocsp-signing.cfg \
  --desc="OCSP signing certificates for revocation services" \
  --store=true

ipa certprofile-mod OCSPSigningCert --enable

# Restrict to OCSP responder services
ipa caacl-add ocsp_signing
ipa caacl-add-profile ocsp_signing --certprofiles=OCSPSigningCert
ipa caacl-add-service ocsp_signing --services=ocsp/responder.example.com
ipa caacl-add-ca ocsp_signing --cas=ipa
ipa caacl-enable ocsp_signing

Wildcard Certificate Profile for Load Balanced Services

Load-balanced web services require wildcard certificates covering multiple subdomains, requiring specific SAN configuration and validation rules.

# Create wildcard certificate profile
ipa certprofile-show caIPAserviceCert --out=/tmp/wildcard-base.cfg

# Modify profile to:
# - Allow wildcards in DNS SAN (*.example.com pattern)
# - Configure subjAltNameExt to accept wildcard patterns
# - Longer validity for load balancer stability (365 days)
# - profileId=WildcardCert

ipa certprofile-import WildcardCert \
  --file=/tmp/wildcard.cfg \
  --desc="Wildcard certificates for load balanced services" \
  --store=true

ipa certprofile-mod WildcardCert --enable

# Restrict to load balancer hosts
ipa caacl-add wildcard_certs
ipa caacl-add-profile wildcard_certs --certprofiles=WildcardCert
ipa caacl-add-host wildcard_certs --hostgroups=load-balancers
ipa caacl-add-ca wildcard_certs --cas=ipa
ipa caacl-enable wildcard_certs

IPsec Certificate Profile with IKE Extended Key Usage

IPsec VPN gateways require certificates with specific IKE-related extended key usages and appropriate subject alternative names for gateway identification.

# Create IPsec certificate profile
ipa certprofile-show caIPAserviceCert --out=/tmp/ipsec-base.cfg

# Modify for IPsec:
# - Extended Key Usage: IKE Intermediate (1.3.6.1.5.5.8.2.2)
# - Also include: serverAuth, clientAuth
# - Key Usage: digitalSignature, keyEncipherment
# - SAN: IP address and DNS name support
# - profileId=IPsecCert

ipa certprofile-import IPsecCert \
  --file=/tmp/ipsec.cfg \
  --desc="IPsec VPN gateway certificates with IKE extensions" \
  --store=true

ipa certprofile-mod IPsecCert --enable

# Associate with VPN gateway hosts
ipa caacl-add ipsec_gateways
ipa caacl-add-profile ipsec_gateways --certprofiles=IPsecCert
ipa caacl-add-host ipsec_gateways --hostgroups=vpn-gateways
ipa caacl-add-ca ipsec_gateways --cas=ipa
ipa caacl-enable ipsec_gateways

Document Signing Certificate Profile for PDF Signatures

Document signing workflows require certificates with appropriate extended key usages for signing documents while preventing misuse for other authentication purposes.

# Create document signing profile
ipa certprofile-show IPA.USER.CERT --out=/tmp/doc-signing-base.cfg

# Modify for document signing:
# - Extended Key Usage: msDocumentSigning (1.3.6.1.4.1.311.10.3.12)
# - Also: emailProtection for email workflows
# - Key Usage: digitalSignature, nonRepudiation
# - Remove authentication-related EKUs
# - profileId=DocumentSigningCert

ipa certprofile-import DocumentSigningCert \
  --file=/tmp/document-signing.cfg \
  --desc="Document signing certificates for PDF and email workflows" \
  --store=true

ipa certprofile-mod DocumentSigningCert --enable

# Allow designated document signers
ipa caacl-add document_signing
ipa caacl-add-profile document_signing --certprofiles=DocumentSigningCert
ipa caacl-add-user document_signing --groups=authorized-signers
ipa caacl-add-ca document_signing --cas=ipa
ipa caacl-enable document_signing

Security Considerations

Profile Import Validation Bypasses Security Constraints

Certificate profile import accepts arbitrary Dogtag profile configurations which may violate IPA security policies or create vulnerabilities. Maliciously crafted profiles can issue certificates with excessive validity periods, inappropriate key usages, or dangerous extensions like CA capabilities when not intended. IPA performs limited validation of profile content during import.

Implement mandatory review processes for all profile imports requiring security team approval. Test profiles in non-production environments before enabling in production. Use profile export from existing validated profiles as templates rather than creating from scratch. Implement automated testing validating profile behavior matches security requirements. Restrict profile import permissions to highly trusted administrators.

Profile Modifications Not Subject to Change Control

Existing certificate profiles can be modified after import by re-importing with updated configurations. These modifications bypass version control and audit trails, potentially introducing security vulnerabilities or compliance violations without detection. Modified profiles immediately affect new certificate requests without migration planning.

Implement infrastructure-as-code approaches storing profile configurations in version control. Require pull request reviews for all profile changes. Use profile description fields to document version and change history. Implement monitoring alerting on profile modifications. Consider treating profile changes as configuration deployment requiring change control windows. Export and backup profiles before modifications.

Disabled Profiles with Existing Certificates Create Confusion

Disabling a certificate profile with certprofile-mod --disable prevents new certificate issuance but does not affect existing certificates issued using the profile. This creates operational confusion when administrators disable compromised profiles expecting all related certificates to become invalid immediately. Certificates remain valid until expiration or explicit revocation.

Implement certificate lifecycle tracking linking certificates to issuing profiles. When disabling profiles, identify and revoke affected certificates: ipa cert-find --certprofile=ProfileName then revoke individually. Document profile disable reasons and affected certificate population. Implement monitoring for certificate requests against disabled profiles. Use shorter validity periods for high-risk profiles to reduce impact of delayed revocation.

Profile Delete Leaves Orphaned Certificates and CA ACLs

Deleting certificate profiles with certprofile-del removes the profile but leaves certificates issued with that profile and CA ACLs referencing it. These orphaned certificates continue functioning but cannot be renewed using the deleted profile. CA ACLs with deleted profile references silently fail to grant access without clear error messages.

Before deleting profiles, identify dependencies: certificates issued using profile (ipa cert-find --certprofile=ProfileName) and CA ACLs referencing it (ipa caacl-find --certprofiles=ProfileName). Document affected certificates and plan migration path to replacement profiles. Update or delete dependent CA ACLs. Export profile configuration for historical records before deletion. Implement profile deprecation process rather than immediate deletion.

Profile Configuration Syntax Errors May Not Be Detected at Import

Dogtag certificate profiles use complex property-list syntax with numerous interrelated configuration parameters. Syntax errors or inconsistent parameter combinations may not be detected during profile import but cause certificate request failures at runtime. Error messages during issuance may be cryptic or misleading.

Implement thorough testing of imported profiles before enabling. Use ipa cert-request with test CSRs to validate profile behavior. Review Dogtag CA debug logs after test requests: /var/log/pki/pki-tomcat/ca/debug. Maintain library of validated profile templates for common use cases. Use profile linting tools if available. Document profile structure and parameter relationships.

Extended Key Usage Misconfigurations Enable Certificate Misuse

Improperly configured Extended Key Usage (EKU) extensions allow certificates to be used for unintended purposes. A certificate intended for email encryption but also including serverAuth EKU can be misused for TLS server authentication. Overly permissive EKU combinations violate principle of least privilege and create attack surfaces.

Implement principle of least privilege for EKU configurations: include only necessary usages. Review profiles for EKU combinations: serverAuth+clientAuth is common for mutual TLS but should not include emailProtection unless needed. Document intended use case for each profile and verify EKU alignment. Use CA ACLs to further restrict profile usage to appropriate principals. Audit existing profiles for overly permissive EKU sets.

Profile Validity Periods Exceeding Organizational Policy

Certificate profiles specify maximum validity periods but administrators can configure excessive durations violating security policies or compliance requirements. Long validity periods increase risk exposure when private keys are compromised and reduce opportunities for access review during renewal.

Establish organizational maximum validity policies by certificate type (user: 1 year, server: 2 years, CA: 10 years). Implement profile review procedures validating validity settings against policy. Use automated testing to verify profile validity constraints. For high-security environments, use shorter validity and rely on automated renewal (certmonger). Document validity period rationale in profile descriptions.

Profile Storage Location Affects Disaster Recovery

Profiles imported with --store=true are stored in IPA LDAP and replicate across servers. Profiles stored only in Dogtag require separate backup and recovery procedures. Mixed storage strategies create operational complexity and disaster recovery risks when profile configurations are inconsistent across servers.

Standardize on --store=true for all profile imports to leverage IPA replication. Implement regular backups of Dogtag profile directories as failsafe: /var/lib/pki/pki-tomcat/ca/profiles/ca/. Document profile storage decisions in operational runbooks. Test disaster recovery procedures including profile restoration. Verify profiles replicate correctly across all IPA servers after import.

Subject DN Component Validation Gaps

Certificate profiles define which subject Distinguished Name (DN) components are required and how they are populated. Insufficient validation of subject DN components allows certificate requests with arbitrary or malicious subject values, potentially enabling impersonation or social engineering attacks via certificate subject information.

Configure profile inputs to validate subject DN components against LDAP attributes. Use constraints limiting allowed values or patterns for subject components. Require CN matching service principal name or user principal. Implement organizational unit (OU) restrictions aligning with organizational structure. Review subject DN population rules in profile PolicySet components. Test with malicious subject values to verify rejection.

Profile Cloning Without Security Review

Administrators often create new profiles by exporting and modifying existing profiles. Cloned profiles may inherit inappropriate configurations from the source profile, including overly permissive settings or extensions unsuitable for the new profile’s intended purpose. Cloning bypasses security review processes applied to original profiles.

Establish profile creation procedures requiring security review regardless of source. Maintain profile template library with pre-approved configurations for common use cases. Document profile inheritance relationships when cloning. Implement automated comparison tools highlighting differences between cloned and source profiles. Require explicit justification for any deviations from approved templates.

Critical Extension Configurations Affecting Certificate Validation

Certificate extensions marked as critical cause validation failures if client software does not recognize the extension OID. Misconfiguring extension criticality (critical vs non-critical) can cause widespread certificate validation failures or security bypasses when critical security extensions are marked non-critical.

Understand X.509 extension criticality semantics before modifying profiles. Test certificates with various clients (browsers, applications, TLS libraries) to verify handling of critical extensions. Common critical extensions: basicConstraints for CA certificates, keyUsage. Common non-critical: subjectAltName, extendedKeyUsage (often). Document criticality decisions in profile configuration comments. Implement test suites validating certificate acceptance across expected client base.

Profile Access Permissions Allow Unauthorized Modifications

IPA permission model controls who can import, modify, and delete certificate profiles. Overly permissive settings allow unauthorized profile modifications introducing vulnerabilities. Default permissions may grant broader access than organizational security policies require.

Review profile-related permissions: ipa permission-find --type=certprofile. Implement role-based access control restricting profile management to PKI administrators. Use custom roles limiting profile operations by profile type or CA. Audit profile permission assignments regularly. Implement approval workflows for profile modifications using ticketing systems integrated with IPA changes.

Inconsistent Profile Configuration Across IPA Replicas

Profile configurations stored in Dogtag (not IPA LDAP with --store=false) may become inconsistent across IPA replicas if profiles are manually modified or imported on subset of servers. Inconsistent profiles cause unpredictable behavior depending on which IPA server processes certificate requests.

Always use --store=true to leverage IPA replication for profile consistency. If Dogtag-only storage is required, implement automation distributing profile files across all servers. Verify profile consistency: export profile from each server and compare SHA256 hashes. Monitor for certificate request failures correlating with specific IPA servers. Implement health checks comparing profile lists across replicas.

Profile Naming and Identification Collisions

Profile IDs must be unique across all profiles and cannot be changed after import. Poorly chosen profile names or ID collisions cause import failures or operational confusion. Generic names like “WebCert” provide insufficient context when dozens of profiles exist for different purposes.

Implement profile naming conventions: environment-type-purpose (e.g., PROD-TLS-WebServer). Use descriptive IDs matching profile purpose. Include version indicators in descriptions: “Web Server Certificate Profile v2.1”. Maintain profile registry documenting all profiles, purposes, and owners. Reserve profile name prefixes by department or team. Validate profile ID uniqueness before import.

Troubleshooting

Profile Import Fails with Syntax Errors

Symptom: certprofile-import command fails with errors like “invalid property”, “profile configuration error”, or other syntax-related messages referencing specific lines in the profile configuration file.

Diagnosis: Validate profile file format is Dogtag property-list syntax (key=value pairs). Check for common syntax errors: missing equals signs, unescaped special characters, incorrect line continuations. Review referenced policy set components exist. Compare against working profile exported from IPA: ipa certprofile-show caIPAserviceCert --out=/tmp/working.cfg.

Resolution: Use text editor with syntax highlighting for property files. Remove any Unicode or non-ASCII characters. Verify all referenced policy components (policyset..default.class, policyset..constraint.class) reference valid Dogtag classes. Check Dogtag documentation for profile syntax. Start from exported working profile and make incremental modifications. Review /var/log/pki/pki-tomcat/ca/debug for detailed error messages during import. Test profile syntax in Dogtag directly before IPA import: pki-server ca-profile-add --raw.

Imported Profile Not Available for Certificate Requests

Symptom: Profile was imported successfully and shows in ipa certprofile-find, but certificate requests fail with “profile not found” or profile does not appear in available profiles list.

Diagnosis: Check if profile is enabled: ipa certprofile-show ProfileName | grep Enabled. Verify profile exists in Dogtag: pki-server ca-profile-show ProfileName. Check if CA ACL grants access to the profile: ipa caacl-find --certprofiles=ProfileName. Review profile was stored in IPA: ipa certprofile-show ProfileName --all | grep "Profile configuration".

Resolution: Enable the profile: ipa certprofile-mod ProfileName --enable. If profile missing from Dogtag, re-import with --store=true which writes to both Dogtag and IPA. Create CA ACL granting access: ipa caacl-add test_acl && ipa caacl-add-profile test_acl --certprofiles=ProfileName. Restart PKI services if profile not appearing: systemctl restart pki-tomcatd@pki-tomcat. Verify requesting user/host has appropriate CA ACL permissions.

Certificate Requests Fail with “Profile Constraint Violated”

Symptom: Certificate requests using a profile fail with messages about constraint violations, forbidden extensions, or policy rejections even though the CSR appears correctly formatted.

Diagnosis: Review certificate request in detail: openssl req -text -noout -in request.csr. Compare CSR contents against profile’s input and constraint policies. Check for requested extensions not permitted by profile. Verify key size meets profile minimum requirements. Review /var/log/pki/pki-tomcat/ca/debug for specific constraint violation details.

Resolution: Modify CSR to comply with profile constraints: adjust key size, remove unauthorized extensions, correct subject DN format. Update profile constraints if legitimate use case requires different parameters: export profile, modify constraint parameters, re-import. For Subject Alternative Name issues, verify SAN extension input configuration matches CSR content. Test with minimal CSR containing only required components to isolate problematic elements.

Profile Modifications Not Taking Effect

Symptom: Profile was re-imported or modified but certificate requests continue using old profile configuration. Changes visible in exported profile but not reflected in issued certificates.

Diagnosis: Check profile modification timestamp: ipa certprofile-show ProfileName --all. Verify profile version in Dogtag matches IPA: compare ipa certprofile-show ProfileName --out=/tmp/ipa.cfg with pki-server ca-profile-show ProfileName --output /tmp/dogtag.cfg. Check if multiple IPA servers exist and profile changes replicated: test on each replica.

Resolution: Force profile update by disabling and re-enabling: ipa certprofile-mod ProfileName --disable && ipa certprofile-mod ProfileName --enable. Restart PKI services to clear profile cache: systemctl restart pki-tomcatd@pki-tomcat. Re-import profile explicitly: ipa certprofile-mod ProfileName --file=/tmp/updated-profile.cfg. Verify replication completed: ipa-replica-manage list and check all replicas. Wait for Dogtag configuration reload (can take several minutes).

Profile Deletion Blocked by Dependency Errors

Symptom: certprofile-del command fails with errors about dependencies, references, or indicating the profile cannot be deleted because it is in use.

Diagnosis: Check for CA ACLs referencing the profile: ipa caacl-find --certprofiles=ProfileName. Look for certificates issued using the profile: ipa cert-find --certprofile=ProfileName. Verify profile is not a built-in system profile which cannot be deleted. Check for pending certificate requests in Dogtag queue.

Resolution: Remove profile from all CA ACLs first: ipa caacl-remove-profile AclName --certprofiles=ProfileName for each ACL. Disable profile before deletion: ipa certprofile-mod ProfileName --disable. Note that existing certificates issued with the profile will continue working after profile deletion. For built-in profiles (caIPAserviceCert, IPA.USER.CERT), these cannot be deleted. Clear any pending requests in Dogtag before attempting deletion.

Profile Export Produces Corrupted or Incomplete File

Symptom: Using certprofile-show --out=file produces file with corrupted content, missing sections, or that cannot be re-imported.

Diagnosis: Check file permissions and disk space: ls -l file && df -h /tmp. Verify file encoding is ASCII: file /tmp/exported-profile.cfg. Compare file size with expected profile size: very small files indicate incomplete write. Review if profile stored in IPA or only Dogtag: ipa certprofile-show ProfileName --all.

Resolution: Use absolute file paths with --out option: ipa certprofile-show ProfileName --out=/tmp/profile.cfg. Verify write permissions to target directory. For profiles not stored in IPA (--store=false during import), export directly from Dogtag: pki-server ca-profile-show ProfileName --output /tmp/profile.cfg. Check for shell redirection issues if piping output. Re-export to different location to rule out filesystem issues.

Certificates Issued with Incorrect Validity Period

Symptom: Certificates issued using a profile have validity periods different than expected, either shorter or longer than profile configuration specifies.

Diagnosis: Review profile validity configuration: export profile and check policyset.*.default.params.range parameter (validity in days). Check for constraint policies limiting maximum validity. Verify Dogtag CA system time is correct: date on IPA server. Review certificate details: openssl x509 -text -noout -in cert.pem | grep -A2 Validity.

Resolution: Correct profile validity parameter: modify profile changing range parameter to desired days, re-import. Verify constraint maximum validity is not lower than default validity: both constraint and default must align. Check Dogtag CA logging for validity calculation: /var/log/pki/pki-tomcat/ca/debug. Ensure system clocks synchronized via NTP. Test with new certificate request after profile modification.

Extended Key Usage Extensions Missing from Issued Certificates

Symptom: Certificates issued using a profile are missing expected Extended Key Usage (EKU) extensions, or have different EKUs than profile configuration specifies.

Diagnosis: Export and review profile configuration for ExtendedKeyUsage policy: look for policyset.*.default.params.exKeyUsageOIDs. Verify OIDs are formatted correctly (e.g., 1.3.6.1.5.5.7.3.1 for serverAuth). Check if EKU is configured as default (automatically added) vs input (requested in CSR). Review issued certificate extensions: openssl x509 -text -noout -in cert.pem | grep -A5 "Extended Key Usage".

Resolution: Modify profile to configure EKU as default policy that automatically adds extensions rather than relying on CSR requests. Verify OID syntax: use numeric OIDs rather than names. Example configuration: policyset.serverCertSet.8.default.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 for serverAuth and clientAuth. Re-import profile and test with new certificate request. Check Dogtag policy configuration in /var/lib/pki/pki-tomcat/ca/profiles/ca/.

Subject Alternative Names Not Populated Correctly

Symptom: Certificates issued using profile have missing or incorrect Subject Alternative Name (SAN) extensions. Expected DNS names, IP addresses, or email addresses do not appear in certificates.

Diagnosis: Review profile SAN configuration: export profile and find SubjectAltName policy sections. Verify SAN input configuration allows requested types (DNS, IP, email). Check CSR contains SAN extension request: openssl req -text -noout -in request.csr | grep -A10 "Subject Alternative Name". Review if profile uses pattern matching or copying from CSR vs LDAP attributes.

Resolution: Configure profile to populate SAN from CSR: ensure SubjectAltName input policy includes subjAltNameExtInputImpl. For host certificates, configure profile to read DNS name from principal: use subjAltNameExtDefaultImpl with pattern parameter pulling from request context. Verify SAN pattern syntax in profile. Test with CSR explicitly including SAN: openssl req -new -key key.pem -out csr.pem -config openssl.cnf with SAN in config. Review Dogtag debug logs for SAN population details.

Profile Shows in List But Cannot Be Displayed

Symptom: Profile appears in ipa certprofile-find output but ipa certprofile-show ProfileName fails with “profile not found” or permission errors.

Diagnosis: Verify exact profile ID: copy from find output to eliminate typos. Check user permissions: ipa permission-find --type=certprofile. Verify profile exists in both IPA and Dogtag: ldapsearch -Y GSSAPI -b "cn=certprofiles,cn=ca,dc=example,dc=com". Check for replication issues between LDAP servers.

Resolution: Use exact profile ID from find output: profile IDs are case-sensitive. Verify user has Certificate Administrator role: ipa role-show 'Certificate Administrators'. If profile exists in LDAP but not Dogtag, may need to restart PKI: systemctl restart pki-tomcatd@pki-tomcat. Check for schema replication issues: ipa-replica-manage list and force sync if needed. Try accessing from different IPA replica to isolate server-specific issues.

Cannot Modify Built-in Certificate Profiles

Symptom: Attempts to modify built-in profiles like caIPAserviceCert, IPA.USER.CERT fail with permission or policy errors indicating profiles cannot be modified.

Diagnosis: Identify if profile is built-in: ipa certprofile-show ProfileName --all | grep System. Check profile origin: IPA system profiles are protected from modification. Review intended changes to determine if new custom profile is more appropriate approach.

Resolution: Do not modify built-in profiles directly; instead create custom profiles based on built-in templates: ipa certprofile-show caIPAserviceCert --out=/tmp/base.cfg, modify file, import as new profile with different ID: ipa certprofile-import CustomServiceCert --file=/tmp/modified.cfg. Use custom profile in CA ACLs instead of built-in profiles. This approach maintains system profiles for default use cases while allowing customization.

Profile Import Succeeds But Certificate Issuance Fails

Symptom: Profile imports without errors and appears enabled, but all certificate requests using the profile fail with cryptic errors during issuance.

Diagnosis: Review Dogtag CA debug logs: /var/log/pki/pki-tomcat/ca/debug for detailed error messages during certificate issuance. Check for references to missing classes, policy errors, or configuration problems. Verify profile references valid Dogtag policy components: compare class references against available Dogtag plugins. Test if profile was imported to Dogtag correctly: pki-server ca-profile-show ProfileName.

Resolution: Verify all policy class names in profile reference installed Dogtag components. Common issue: referencing plugins not available in current Dogtag version. Compare profile against profiles known to work: use built-in profiles as reference for correct class names and structure. Check Dogtag version compatibility: pki-server --version. Review Dogtag documentation for profile schema and available policy components. Re-create profile from validated template if issues persist.

Profile Replication Not Synchronizing Across IPA Servers

Symptom: Profile imported on one IPA server does not appear on other replicas, or appears with different configuration. Certificate requests fail on some servers but succeed on others.

Diagnosis: Check if profile was imported with --store=true: profiles not stored in IPA LDAP will not replicate. Verify IPA replication status: ipa-replica-manage list and check for replication errors. Compare profile on each server: ipa certprofile-show ProfileName --out=/tmp/server1.cfg on each replica and diff files.

Resolution: Always import profiles with --store=true to leverage IPA replication: ipa certprofile-import ProfileName --file=profile.cfg --store=true. Force immediate replication: ipa-replica-manage force-sync --from=source-server.example.com. For profiles already imported without store, delete and re-import on master with --store=true, then force replication. Verify profile presence on all replicas before enabling and creating CA ACLs. Check LDAP replication status and resolve any conflicts before profile deployment.

Profile Constraint Errors Not Providing Useful Information

Symptom: Certificate requests fail with generic “constraint violation” errors without specifying which constraint was violated or what values are acceptable.

Diagnosis: Enable verbose IPA logging: edit /etc/ipa/server.conf and set debug = True, restart httpd: systemctl restart httpd. Review full Dogtag debug logs: /var/log/pki/pki-tomcat/ca/debug which contain detailed constraint validation results. Export profile and manually review all constraint policies for the likely issue.

Resolution: Use Dogtag debug logs to identify specific constraint violations: look for policy name and violation details. Common constraints: key size minimum, validity period maximum, subject DN component patterns. Test with simplified CSR containing minimal required fields to isolate problematic components. Adjust profile constraints if violations indicate overly restrictive policies: modify constraint parameter values and re-import. Create test procedures exercising profile constraints with known good and bad CSRs for validation. After troubleshooting, restore normal logging levels.