CA ACL Rules
Manage certificate authority access control lists to restrict which certificate profiles can be used by which users, hosts, or services. CA ACLs enforce policy by controlling profile usage, target principals, and issuing CAs. Features include rule-based access control, profile and CA filtering, user and host category support, and enable/disable capabilities for flexible certificate issuance governance.
Overview
Certificate Authority Access Control Lists (CA ACLs) provide fine-grained control over certificate issuance by defining which principals (users, hosts, services) can request certificates using which certificate profiles from which certificate authorities. CA ACLs enforce certificate issuance policy at a granular level, enabling organizations to implement security controls and compliance requirements.
Without CA ACLs, anyone who can authenticate to IPA could potentially request any type of certificate from any CA using any profile. CA ACLs prevent this by requiring explicit permission grants that specify:
Who (subject principals): Which users, groups, hosts, hostgroups, or services What (certificate profiles): Which certificate templates/types Where (certificate authorities): Which CAs (root or subordinate)
A certificate request succeeds only if there exists an enabled CA ACL that includes:
- The subject principal (who the certificate is for)
- The certificate profile being used
- The CA being requested from
This three-dimensional access control model enables powerful policy enforcement scenarios like restricting code-signing certificates to specific developer groups, limiting VPN certificates to specific user populations, or confining IoT device certificates to specific subordinate CAs.
CA ACL Model
Three-Dimensional Authorization
CA ACLs define allowed combinations of three dimensions:
Dimension 1: Subject Principals (WHO gets the certificate)
- Individual users (e.g.,
alice,bob) - User groups (e.g.,
developers,employees) - Individual hosts (e.g.,
web1.example.com,db1.example.com) - Host groups (e.g.,
webservers,databases) - Individual services (e.g.,
HTTP/web1.example.com) - Category: “all users”, “all hosts”, “all services”
Dimension 2: Certificate Profiles (WHAT type of certificate)
- Specific profiles by name (e.g.,
caIPAserviceCert,IECUserRoles) - Multiple profiles per ACL
- Profiles define certificate templates, extensions, constraints
Dimension 3: Certificate Authorities (WHERE certificate is issued from)
- Specific CAs by name (e.g.,
ipa,puppet,vpn) - Multiple CAs per ACL
- Category: “all CAs”
- Default: If no CA specified, implies
ipaCA only (backward compatibility)
Authorization Logic
For a certificate request to succeed:
EXISTS enabled CA ACL WHERE:
- Subject principal ∈ ACL's principal scope AND
- Certificate profile ∈ ACL's profile scope AND
- Certificate authority ∈ ACL's CA scopeIf multiple CA ACLs match, the request succeeds (logical OR). If no CA ACL matches, the request fails (default deny).
Important: The subject principal is the entity the certificate is for, not necessarily the requesting principal. For example, an administrator might request a certificate for a user; the CA ACL checks the user, not the administrator (assuming the administrator has “bypass CA ACL” privilege).
Categories vs Explicit Membership
CA ACLs support two membership modes:
Explicit membership: Specific named principals
- Example: Users
alice,bob,charlie - Granular control, but requires maintenance as membership changes
Category membership: All principals of a type
--usercat=all: All users--hostcat=all: All hosts--servicecat=all: All services--cacat=all: All CAs- Broad access, less maintenance, but less granular
Mixed mode: Some dimensions explicit, others categorical
- Example: All users (
--usercat=all) can use specific profile on specific CA - Common for broadly-applicable profiles like standard user certificates
Subject Principal Scope
User Scope
Individual users: Specific user accounts
$ ipa caacl-add-user my-acl --users=alice,bobUser groups: All members of specified groups
$ ipa caacl-add-user my-acl --groups=developers,engineersAll users category: Every user in IPA
$ ipa caacl-add my-acl --usercat=allUse cases:
- Individual users: Rarely used; prefer groups for maintainability
- User groups: Most common; aligns with organizational structure
- All users: Broad profiles like basic user certificates available to everyone
Host Scope
Individual hosts: Specific host entries
$ ipa caacl-add-host my-acl --hosts=web1.example.com,web2.example.comHost groups: All members of specified hostgroups
$ ipa caacl-add-host my-acl --hostgroups=webservers,databasesAll hosts category: Every host in IPA
$ ipa caacl-add my-acl --hostcat=allUse cases:
- Individual hosts: Specific servers requiring unique profiles
- Host groups: Common; group servers by function (web, database, etc.)
- All hosts: Standard host certificates for all enrolled systems
Service Scope
Individual services: Specific service principals
$ ipa caacl-add-service my-acl --services=HTTP/web1.example.com,ldap/ipa1.example.comAll services category: Every service in IPA
$ ipa caacl-add my-acl --servicecat=allUse cases:
- Individual services: Application-specific certificates
- All services: Standard service certificates for all service types
Mixed Principal Types
A single CA ACL can include multiple principal types:
$ ipa caacl-add web-vpn-acl
$ ipa caacl-add-user web-vpn-acl --groups=remote-workers
$ ipa caacl-add-host web-vpn-acl --hostgroups=vpn-gatewaysThis ACL allows remote workers (users) and VPN gateways (hosts) to request certificates, useful when a single profile serves multiple principal types.
Certificate Authority Scope
Specific CAs
Grant access to named CAs (root or subordinate):
$ ipa caacl-add-ca my-acl --cas=ipa,puppet,vpnThis restricts certificate requests to the specified CAs only.
All CAs Category
Grant access to all CAs (present and future):
$ ipa caacl-add my-acl --cacat=allUseful for administrative roles or broadly-applicable profiles.
Default CA Scope
If no CA is specified when creating the ACL, it defaults to the ipa CA only (backward compatibility):
$ ipa caacl-add my-acl
# Implicitly: --cas=ipaTo use subordinate CAs, explicitly add them to the ACL.
CA Scope Use Cases
Single CA: Restrict certificate type to specific CA
- Example: Code signing certificates only from
code-signingCA
Multiple CAs: Allow profile across several CAs
- Example: Service certificates from
ipaandpuppetCAs
All CAs: Administrative or universal profiles
- Example: Administrators can use any profile on any CA
Certificate Profile Scope
Adding Profiles
Profiles must be explicitly added to CA ACLs:
$ ipa caacl-add-profile my-acl --certprofiles=caIPAserviceCert,caIPAuserCertMultiple profiles can be added in one command or incrementally.
Profile Restrictions
CA ACLs enable policy enforcement via profile restrictions:
Restrict powerful profiles: Limit code-signing or CA-signing profiles to specific groups
Separate user vs service certificates: Different ACLs for user and service certificate profiles
Environment separation: Development profiles accessible to all, production profiles restricted
Compliance: Limit EV (Extended Validation) certificate profiles to approved users
Profile Naming
Certificate profiles are identified by Profile ID (case-sensitive):
- Format: Start with letter, followed by letters/digits/underscore
- Examples:
caIPAserviceCert,IECUserRoles,caJavaAppletCert - List available:
ipa certprofile-find
Enabled vs Disabled State
Enabled ACLs
Enabled CA ACLs are evaluated for certificate requests:
$ ipa caacl-enable my-aclOnly enabled ACLs grant certificate issuance permissions.
Disabled ACLs
Disabled CA ACLs are ignored during authorization:
$ ipa caacl-disable my-aclDisabling an ACL temporarily revokes the permissions it grants without deleting the ACL configuration. Useful for:
- Incident response (temporarily block certificate issuance)
- Maintenance windows (disable while restructuring ACLs)
- Testing (disable production ACLs in test environments)
Default State
New CA ACLs are enabled by default upon creation.
Examples
Basic User Certificate ACL
# Allow all users to request user certificates from ipa CA
$ ipa caacl-add "Users get user certs" --usercat=all
$ ipa caacl-add-ca "Users get user certs" --cas=ipa
$ ipa caacl-add-profile "Users get user certs" --certprofiles=caIPAuserCert
ACL name: Users get user certs
Enabled: TRUE
User category: all
CAs: ipa
Profiles: caIPAuserCertService Certificate ACL for Admins
# Allow sysadmins group to request service certificates for any service
$ ipa caacl-add "Admins manage service certs"
$ ipa caacl-add-user "Admins manage service certs" --groups=sysadmins
$ ipa caacl-add-ca "Admins manage service certs" --cas=ipa
$ ipa caacl-add-profile "Admins manage service certs" --certprofiles=caIPAserviceCert
$ ipa caacl-add-service "Admins manage service certs" --servicecat=allHost Certificate ACL
# Allow webservers hostgroup to request host certificates
$ ipa caacl-add "Webservers get host certs"
$ ipa caacl-add-host "Webservers get host certs" --hostgroups=webservers
$ ipa caacl-add-ca "Webservers get host certs" --cas=ipa
$ ipa caacl-add-profile "Webservers get host certs" --certprofiles=caIPAserviceCertSubordinate CA ACL
# Allow developers to request certificates from puppet CA
$ ipa caacl-add "Developers use Puppet CA"
$ ipa caacl-add-user "Developers use Puppet CA" --groups=developers
$ ipa caacl-add-ca "Developers use Puppet CA" --cas=puppet
$ ipa caacl-add-profile "Developers use Puppet CA" --certprofiles=caIPAserviceCertCode Signing ACL
# Restrict code signing certificates to build engineers
$ ipa caacl-add "Build engineers code signing"
$ ipa caacl-add-user "Build engineers code signing" --groups=build-engineers
$ ipa caacl-add-ca "Build engineers code signing" --cas=code-signing
$ ipa caacl-add-profile "Build engineers code signing" --certprofiles=caCodeSigningCertVPN Certificate ACL
# Allow remote workers to get VPN certificates from vpn CA
$ ipa caacl-add "Remote workers VPN"
$ ipa caacl-add-user "Remote workers VPN" --groups=remote-workers
$ ipa caacl-add-ca "Remote workers VPN" --cas=vpn
$ ipa caacl-add-profile "Remote workers VPN" --certprofiles=caIPAvpnCertMulti-CA ACL
# Allow service principals to use multiple CAs
$ ipa caacl-add "Services multi-CA"
$ ipa caacl-add-service "Services multi-CA" --servicecat=all
$ ipa caacl-add-ca "Services multi-CA" --cas=ipa,puppet,app-services
$ ipa caacl-add-profile "Services multi-CA" --certprofiles=caIPAserviceCertMultiple Profile ACL
# Allow specific users to request multiple certificate types
$ ipa caacl-add "Alice multi-profile"
$ ipa caacl-add-user "Alice multi-profile" --users=alice
$ ipa caacl-add-ca "Alice multi-profile" --cas=ipa
$ ipa caacl-add-profile "Alice multi-profile" \
--certprofiles=caIPAuserCert,caIPAuserSMIME,caIPAuserClientAuthMixed Principal Types ACL
# Allow users and services to request certificates
$ ipa caacl-add "Users and services"
$ ipa caacl-add-user "Users and services" --groups=employees
$ ipa caacl-add-service "Users and services" --servicecat=all
$ ipa caacl-add-ca "Users and services" --cas=ipa
$ ipa caacl-add-profile "Users and services" --certprofiles=caIPAserviceCertList All CA ACLs
# View all CA ACL rules
$ ipa caacl-find
5 CA ACLs matched
ACL name: Users get user certs
Enabled: TRUE
ACL name: Admins manage service certs
Enabled: TRUE
[...]Show CA ACL Details
# View specific CA ACL configuration
$ ipa caacl-show "Users get user certs"
ACL name: Users get user certs
Enabled: TRUE
User category: all
CAs: ipa
Profiles: caIPAuserCertDisable CA ACL
# Temporarily disable ACL without deleting
$ ipa caacl-disable "Remote workers VPN"
Disabled CA ACL "Remote workers VPN"
# Verify disabled
$ ipa caacl-show "Remote workers VPN" | grep Enabled
Enabled: FALSERe-enable CA ACL
# Re-enable previously disabled ACL
$ ipa caacl-enable "Remote workers VPN"
Enabled CA ACL "Remote workers VPN"Remove Specific Members
# Remove a CA from an ACL
$ ipa caacl-remove-ca "Services multi-CA" --cas=app-services
# Remove a profile from an ACL
$ ipa caacl-remove-profile "Alice multi-profile" --certprofiles=caIPAuserSMIME
# Remove a user group from an ACL
$ ipa caacl-remove-user "Developers use Puppet CA" --groups=developersDelete CA ACL
# Permanently remove CA ACL
$ ipa caacl-del "Alice multi-profile"
Deleted CA ACL "Alice multi-profile"Modify CA ACL Description
# Update ACL description
$ ipa caacl-mod "Users get user certs" \
--desc="Standard user certificate access for all IPA users"Search CA ACLs
# Find ACLs by name pattern
$ ipa caacl-find --name="*VPN*"
# Find enabled ACLs
$ ipa caacl-find --enabled=TRUE
# Find ACLs with specific CA
$ ipa caacl-find --cas=puppetComplex Multi-Dimensional ACL
# Create comprehensive ACL for engineering department
$ ipa caacl-add "Engineering comprehensive"
# Add user groups
$ ipa caacl-add-user "Engineering comprehensive" \
--groups=engineering-staff,engineering-contractors
# Add host groups
$ ipa caacl-add-host "Engineering comprehensive" \
--hostgroups=engineering-servers,engineering-workstations
# Add services (all)
$ ipa caacl-add-service "Engineering comprehensive" --servicecat=all
# Add multiple CAs
$ ipa caacl-add-ca "Engineering comprehensive" \
--cas=ipa,engineering-dev,engineering-staging
# Add multiple profiles
$ ipa caacl-add-profile "Engineering comprehensive" \
--certprofiles=caIPAuserCert,caIPAserviceCert,caIPAhostCertTemporary Test ACL
# Create ACL for testing, immediately disable
$ ipa caacl-add "Test ACL" --usercat=all --cacat=all
$ ipa caacl-add-profile "Test ACL" --certprofiles=caIPAtestCert
$ ipa caacl-disable "Test ACL"
# Enable when ready to test
$ ipa caacl-enable "Test ACL"
# Disable after testing
$ ipa caacl-disable "Test ACL"
# Delete when test complete
$ ipa caacl-del "Test ACL"Best Practices
Design Principles
Least privilege: Grant certificate issuance permissions only to principals that need them. Don’t use --usercat=all unless truly every user should have access.
Group-based membership: Use groups instead of individual principals for easier maintenance. Add/remove users from groups rather than modifying ACLs.
Clear naming: Use descriptive ACL names that explain what’s granted: “Engineering VPN Certs” rather than “ACL1”.
Separate user/host/service ACLs: Create distinct ACLs for different principal types even if they use the same profiles. This improves clarity and enables future divergence.
Profile specificity: Don’t grant access to all profiles if only specific ones are needed. Be explicit about which profiles each principal type can use.
Security Considerations
Restrict powerful profiles: Certificate profiles that grant extended capabilities (code signing, CA signing, OCSP signing) should have very restrictive ACLs limited to administrators.
Subordinate CA isolation: Use CA ACLs to restrict subordinate CA access to specific groups, enforcing the separation of concerns that subordinate CAs provide.
Regular audits: Periodically review CA ACLs to ensure they still align with organizational access policies. Remove obsolete ACLs.
Test before production: Create and test new CA ACLs in non-production environments before deploying to production.
Monitor certificate requests: Log and monitor certificate requests, especially failures due to CA ACL denials. Unusual patterns may indicate misconfiguration or attacks.
Avoid wildcards carefully: --usercat=all, --hostcat=all, --servicecat=all, --cacat=all grant broad access. Use only when truly appropriate.
Operational Practices
Document ACL purposes: Maintain documentation explaining why each CA ACL exists, which business requirement it satisfies, and who requested it.
Change management: Treat CA ACL changes like other access control modifications—require approval and document changes.
Incremental deployment: When rolling out new certificate types, start with restricted ACLs (specific groups) and expand gradually based on demand.
Disable vs delete: Prefer disabling ACLs over deletion when temporarily suspending access. Disabling preserves configuration for future re-enablement.
Versioning: When significantly changing an ACL, consider creating a new ACL with a versioned name rather than modifying the existing one. This maintains audit trail and enables rollback.
ACL Composition
Separate environments: Create distinct ACLs for production, staging, and development, even if they grant similar access. This enables environment-specific restrictions.
Layer security: Combine CA ACLs with certificate profile constraints for defense-in-depth. ACLs control who can request, profiles control what’s in the certificate.
Future-proof: When adding new CAs or profiles, review existing ACLs to determine if they should include the new CA/profile or if new ACLs are needed.
Integration Points
Certificate Authorities
CA ACLs reference CAs by name:
Root CA: ipa - Always available
Subordinate CAs: Names defined when CA is created via ca-add
All CAs category: Includes all CAs present and future
Commands: ca-find, ca-show, ca-add
Certificate Profiles
CA ACLs reference certificate profiles by Profile ID:
Built-in profiles: Provided by IPA (e.g., caIPAserviceCert, caIPAuserCert)
Custom profiles: Imported by administrators via certprofile-import
Profile discovery: List with certprofile-find
Commands: certprofile-find, certprofile-show, certprofile-import
Certificate Requests
CA ACLs are evaluated during certificate requests:
Certificate request: cert-request checks if requesting principal is authorized via CA ACLs
Subject principal: ACL checks the certificate subject (who cert is for), not requester
Bypass privilege: Users with “Request Certificate ignoring CA ACLs” privilege bypass CA ACL checks
Commands: cert-request, cert-show
Users and Groups
CA ACLs reference users and groups:
User membership: Individual users or groups can be added to ACLs Group changes: Adding/removing users from groups automatically affects ACL scope All users category: Includes all users present and future
Commands: user-find, group-find, group-add-member
Hosts and Host Groups
CA ACLs reference hosts and hostgroups:
Host membership: Individual hosts or hostgroups can be added to ACLs Hostgroup changes: Adding/removing hosts from hostgroups automatically affects ACL scope All hosts category: Includes all hosts present and future
Commands: host-find, hostgroup-find, hostgroup-add-member
Services
CA ACLs reference service principals:
Service membership: Individual service principals can be added to ACLs
All services category: Includes all services present and future
Service format: SERVICE/hostname (e.g., HTTP/web1.example.com)
Commands: service-find, service-show
RBAC
CA ACL management requires appropriate permissions:
“System: Add CA ACL”: Create new CA ACLs “System: Modify CA ACL”: Modify existing CA ACLs, add/remove members “System: Delete CA ACL”: Delete CA ACLs “System: Read CA ACLs”: View CA ACL configuration
These permissions are typically granted via the “Certificate Administrator” role.
Replication
CA ACL configuration replicates across IPA servers:
LDAP replication: CA ACL entries replicate to all IPA replicas Evaluation: Any IPA server can evaluate CA ACLs for certificate requests Consistency: Changes propagate within minutes (depending on replication topology)
Commands
caacl-add
Usage: ipa [global-options] caacl-add NAME [options]
Create a new CA ACL.
Arguments
| Argument | Required | Description |
|---|---|---|
NAME | yes | ACL name |
Options
| Option | Description |
|---|---|
--desc DESC | Description |
--cacat CACAT | CA category the ACL applies to |
--profilecat PROFILECAT | Profile category the ACL applies to |
--usercat USERCAT | User category the ACL applies to |
--hostcat HOSTCAT | Host category the ACL applies to |
--servicecat SERVICECAT | Service category the ACL applies to |
--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 |
--all | Retrieve and print all attributes from the server. Affects command output. |
--raw | Print entries as stored on the server. Only affects output format. |
--no-members | Suppress processing of membership attributes. |
caacl-add-ca
Usage: ipa [global-options] caacl-add-ca NAME [options]
Add CAs to a CA ACL.
Arguments
| Argument | Required | Description |
|---|---|---|
NAME | yes | ACL name |
Options
| Option | Description |
|---|---|
--all | Retrieve and print all attributes from the server. Affects command output. |
--raw | Print entries as stored on the server. Only affects output format. |
--no-members | Suppress processing of membership attributes. |
--cas CAS | Certificate Authorities to add |
caacl-add-host
Usage: ipa [global-options] caacl-add-host NAME [options]
Add target hosts and hostgroups to a CA ACL.
Arguments
| Argument | Required | Description |
|---|---|---|
NAME | yes | ACL name |
Options
| Option | Description |
|---|---|
--all | Retrieve and print all attributes from the server. Affects command output. |
--raw | Print entries as stored on the server. Only affects output format. |
--no-members | Suppress processing of membership attributes. |
--hosts HOSTS | hosts to add |
--hostgroups HOSTGROUPS | host groups to add |
caacl-add-profile
Usage: ipa [global-options] caacl-add-profile NAME [options]
Add profiles to a CA ACL.
Arguments
| Argument | Required | Description |
|---|---|---|
NAME | yes | ACL name |
Options
| Option | Description |
|---|---|
--all | Retrieve and print all attributes from the server. Affects command output. |
--raw | Print entries as stored on the server. Only affects output format. |
--no-members | Suppress processing of membership attributes. |
--certprofiles CERTPROFILES | Certificate Profiles to add |
caacl-add-service
Usage: ipa [global-options] caacl-add-service NAME [options]
Add services to a CA ACL.
Arguments
| Argument | Required | Description |
|---|---|---|
NAME | yes | ACL name |
Options
| Option | Description |
|---|---|
--all | Retrieve and print all attributes from the server. Affects command output. |
--raw | Print entries as stored on the server. Only affects output format. |
--no-members | Suppress processing of membership attributes. |
--services SERVICES | services to add |
caacl-add-user
Usage: ipa [global-options] caacl-add-user NAME [options]
Add users and groups to a CA ACL.
Arguments
| Argument | Required | Description |
|---|---|---|
NAME | yes | ACL name |
Options
| Option | Description |
|---|---|
--all | Retrieve and print all attributes from the server. Affects command output. |
--raw | Print entries as stored on the server. Only affects output format. |
--no-members | Suppress processing of membership attributes. |
--users USERS | users to add |
--groups GROUPS | groups to add |
caacl-del
Usage: ipa [global-options] caacl-del NAME [options]
Delete a CA ACL.
Arguments
| Argument | Required | Description |
|---|---|---|
NAME | yes | ACL name |
Options
| Option | Description |
|---|---|
--continue | Continuous mode: Don’t stop on errors. |
caacl-disable
Usage: ipa [global-options] caacl-disable NAME [options]
Disable a CA ACL.
Arguments
| Argument | Required | Description |
|---|---|---|
NAME | yes | ACL name |
caacl-enable
Usage: ipa [global-options] caacl-enable NAME [options]
Enable a CA ACL.
Arguments
| Argument | Required | Description |
|---|---|---|
NAME | yes | ACL name |
caacl-find
Usage: ipa [global-options] caacl-find [CRITERIA] [options]
Search for CA ACLs.
Arguments
Argument Required Description
CRITERIA no A string searched in all relevant object
attributes
Options
| Option | Description |
|---|---|
--name NAME | ACL name |
--desc DESC | Description |
--cacat CACAT | CA category the ACL applies to |
--profilecat PROFILECAT | Profile category the ACL applies to |
--usercat USERCAT | User category the ACL applies to |
--hostcat HOSTCAT | Host category the ACL applies to |
--servicecat SERVICECAT | Service category the ACL applies to |
--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 (“name”) |
caacl-mod
Usage: ipa [global-options] caacl-mod NAME [options]
Modify a CA ACL.
Arguments
| Argument | Required | Description |
|---|---|---|
NAME | yes | ACL name |
Options
| Option | Description |
|---|---|
--desc DESC | Description |
--cacat CACAT | CA category the ACL applies to |
--profilecat PROFILECAT | Profile category the ACL applies to |
--usercat USERCAT | User category the ACL applies to |
--hostcat HOSTCAT | Host category the ACL applies to |
--servicecat SERVICECAT | Service category the ACL applies to |
--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. |
--all | Retrieve and print all attributes from the server. Affects command output. |
--raw | Print entries as stored on the server. Only affects output format. |
--no-members | Suppress processing of membership attributes. |
caacl-remove-ca
Usage: ipa [global-options] caacl-remove-ca NAME [options]
Remove CAs from a CA ACL.
Arguments
| Argument | Required | Description |
|---|---|---|
NAME | yes | ACL name |
Options
| Option | Description |
|---|---|
--all | Retrieve and print all attributes from the server. Affects command output. |
--raw | Print entries as stored on the server. Only affects output format. |
--no-members | Suppress processing of membership attributes. |
--cas CAS | Certificate Authorities to remove |
caacl-remove-host
Usage: ipa [global-options] caacl-remove-host NAME [options]
Remove target hosts and hostgroups from a CA ACL.
Arguments
| Argument | Required | Description |
|---|---|---|
NAME | yes | ACL name |
Options
| Option | Description |
|---|---|
--all | Retrieve and print all attributes from the server. Affects command output. |
--raw | Print entries as stored on the server. Only affects output format. |
--no-members | Suppress processing of membership attributes. |
--hosts HOSTS | hosts to remove |
--hostgroups HOSTGROUPS | host groups to remove |
caacl-remove-profile
Usage: ipa [global-options] caacl-remove-profile NAME [options]
Remove profiles from a CA ACL.
Arguments
| Argument | Required | Description |
|---|---|---|
NAME | yes | ACL name |
Options
| Option | Description |
|---|---|
--all | Retrieve and print all attributes from the server. Affects command output. |
--raw | Print entries as stored on the server. Only affects output format. |
--no-members | Suppress processing of membership attributes. |
--certprofiles CERTPROFILES | Certificate Profiles to remove |
caacl-remove-service
Usage: ipa [global-options] caacl-remove-service NAME [options]
Remove services from a CA ACL.
Arguments
| Argument | Required | Description |
|---|---|---|
NAME | yes | ACL name |
Options
| Option | Description |
|---|---|
--all | Retrieve and print all attributes from the server. Affects command output. |
--raw | Print entries as stored on the server. Only affects output format. |
--no-members | Suppress processing of membership attributes. |
--services SERVICES | services to remove |
caacl-remove-user
Usage: ipa [global-options] caacl-remove-user NAME [options]
Remove users and groups from a CA ACL.
Arguments
| Argument | Required | Description |
|---|---|---|
NAME | yes | ACL name |
Options
| Option | Description |
|---|---|
--all | Retrieve and print all attributes from the server. Affects command output. |
--raw | Print entries as stored on the server. Only affects output format. |
--no-members | Suppress processing of membership attributes. |
--users USERS | users to remove |
--groups GROUPS | groups to remove |
caacl-show
Usage: ipa [global-options] caacl-show NAME [options]
Display the properties of a CA ACL.
Arguments
| Argument | Required | Description |
|---|---|---|
NAME | yes | ACL name |
Options
| Option | Description |
|---|---|
--rights | Display the access rights of this entry (requires —all). See ipa man page for details. |
--all | Retrieve and print all attributes from the server. Affects command output. |
--raw | Print entries as stored on the server. Only affects output format. |
--no-members | Suppress processing of membership attributes. |
Use Cases
Smart Card Authentication with Restricted User Certificates
Organizations deploying smart card authentication need to restrict which users can obtain smart card certificates to prevent unauthorized certificate issuance to contractors or temporary accounts.
# Create CA ACL allowing only employees to request smart card certificates
ipa caacl-add employee_smartcards
ipa caacl-add-profile employee_smartcards --certprofiles=caIPAserviceCert
ipa caacl-add-user employee_smartcards --groups=employees
# Add the default IPA CA
ipa caacl-add-ca employee_smartcards --cas=ipa
# Enable the ACL to enforce the policy
ipa caacl-enable employee_smartcards
# Contractors attempting smart card cert requests will be denied
# Only members of employees group can request caIPAserviceCert profileSeparate TLS Certificate Authorities for Production and Development
Enterprises maintaining separate CAs for production and development environments use CA ACLs to ensure development systems cannot obtain production-trusted certificates.
# Create subordinate CA for development (configured elsewhere via Dogtag)
# Assume prod-ca and dev-ca exist in IPA
# Create ACL for production TLS certificates
ipa caacl-add prod_tls_certs
ipa caacl-add-profile prod_tls_certs --certprofiles=caIPAserviceCert
ipa caacl-add-host prod_tls_certs --hostgroups=production-servers
ipa caacl-add-ca prod_tls_certs --cas=prod-ca
ipa caacl-enable prod_tls_certs
# Create ACL for development TLS certificates
ipa caacl-add dev_tls_certs
ipa caacl-add-profile dev_tls_certs --certprofiles=caIPAserviceCert
ipa caacl-add-host dev_tls_certs --hostgroups=dev-servers
ipa caacl-add-ca dev_tls_certs --cas=dev-ca
ipa caacl-enable dev_tls_certs
# Production hosts cannot request certs from dev-ca and vice versaDelegated Certificate Management for Department Administrators
Large organizations delegate certificate issuance authority to department administrators while maintaining central control over which profiles and CAs can be used.
# Create custom certificate profile for web server certificates
# (profile creation done via Dogtag, imported to IPA)
# Create CA ACL for IT department web server certificates
ipa caacl-add it_web_certs
ipa caacl-add-profile it_web_certs --certprofiles=WebServerCert
ipa caacl-add-service it_web_certs --services=HTTP/web1.example.com
ipa caacl-add-service it_web_certs --services=HTTP/web2.example.com
ipa caacl-add-user it_web_certs --groups=it-cert-admins
ipa caacl-add-ca it_web_certs --cas=ipa
ipa caacl-enable it_web_certs
# Members of it-cert-admins group can request WebServerCert profile
# only for explicitly listed HTTP servicesTemporary Certificate Access for External Consultants
Consultants requiring temporary certificate access need time-limited permissions that can be quickly granted and revoked without modifying permanent CA ACL structures.
# Create CA ACL for consultant certificate access
ipa caacl-add consultant_access
ipa caacl-add-profile consultant_access --certprofiles=caIPAserviceCert
ipa caacl-add-user consultant_access --users=consultant1
ipa caacl-add-user consultant_access --users=consultant2
ipa caacl-add-ca consultant_access --cas=ipa
ipa caacl-enable consultant_access
# When consultant engagement ends, disable ACL immediately
ipa caacl-disable consultant_access
# Re-enable if needed for future engagements
ipa caacl-enable consultant_access
# Permanent removal after engagement completes
ipa caacl-del consultant_accessHost-Specific Certificate Profiles for Different System Roles
Different server roles (databases, web servers, application servers) require different certificate types with appropriate key usage and extended key usage extensions enforced via certificate profiles.
# Create CA ACLs for different server roles using different profiles
# Database servers use DB-specific profile with server auth only
ipa caacl-add db_server_certs
ipa caacl-add-profile db_server_certs --certprofiles=DatabaseServerCert
ipa caacl-add-host db_server_certs --hostgroups=database-servers
ipa caacl-add-ca db_server_certs --cas=ipa
ipa caacl-enable db_server_certs
# Web servers use profile allowing both server and client auth
ipa caacl-add web_server_certs
ipa caacl-add-profile web_server_certs --certprofiles=WebServerCert
ipa caacl-add-host web_server_certs --hostgroups=web-servers
ipa caacl-add-ca web_server_certs --cas=ipa
ipa caacl-enable web_server_certs
# Each hostgroup can only request their designated profileRestricting Code Signing Certificates to Build Systems
Code signing certificates must be tightly controlled to prevent unauthorized code signing. CA ACLs restrict code signing profiles to dedicated build infrastructure.
# Create highly restrictive ACL for code signing certificates
ipa caacl-add code_signing
ipa caacl-add-profile code_signing --certprofiles=CodeSigningCert
ipa caacl-add-host code_signing --hosts=build01.example.com
ipa caacl-add-host code_signing --hosts=build02.example.com
ipa caacl-add-ca code_signing --cas=code-signing-ca
ipa caacl-enable code_signing
# Only explicitly listed build hosts can request code signing certs
# No group or category memberships to prevent accidental expansion
# Uses dedicated sub-CA specifically for code signingMulti-Tier CA Hierarchy with Profile-Based Routing
Organizations with complex PKI hierarchies route different certificate types to appropriate CAs based on certificate purpose and security requirements.
# High-security certificates from root CA
ipa caacl-add root_ca_certs
ipa caacl-add-profile root_ca_certs --certprofiles=HighSecurityCert
ipa caacl-add-user root_ca_certs --groups=security-officers
ipa caacl-add-ca root_ca_certs --cas=root-ca
ipa caacl-enable root_ca_certs
# Standard certificates from intermediate CA
ipa caacl-add intermediate_ca_certs
ipa caacl-add-profile intermediate_ca_certs --certprofiles=caIPAserviceCert
ipa caacl-add-user intermediate_ca_certs --groups=all-users
ipa caacl-add-ca intermediate_ca_certs --cas=intermediate-ca
ipa caacl-enable intermediate_ca_certs
# Low-trust certificates from separate intermediate CA
ipa caacl-add test_ca_certs
ipa caacl-add-profile test_ca_certs --certprofiles=TestCert
ipa caacl-add-user test_ca_certs --groups=developers
ipa caacl-add-ca test_ca_certs --cas=test-ca
ipa caacl-enable test_ca_certsService-Specific Certificates with Principal Restrictions
Applications requiring service principals with specific certificate types use CA ACLs to ensure only designated services can obtain their required certificates.
# LDAP service certificates for directory servers
ipa caacl-add ldap_service_certs
ipa caacl-add-profile ldap_service_certs --certprofiles=LDAPServiceCert
ipa caacl-add-service ldap_service_certs \
--services=ldap/ds01.example.com \
--services=ldap/ds02.example.com
ipa caacl-add-ca ldap_service_certs --cas=ipa
ipa caacl-enable ldap_service_certs
# HTTP service certificates for web applications
ipa caacl-add http_service_certs
ipa caacl-add-profile http_service_certs --certprofiles=WebServiceCert
ipa caacl-add-service http_service_certs --services=HTTP/app.example.com
ipa caacl-add-ca http_service_certs --cas=ipa
ipa caacl-enable http_service_certs
# Each service type can only use its designated profileCategory-Based Blanket Access for Standard User Certificates
Organizations with standard certificate needs for all users can use category members to grant universal access while maintaining profile restrictions.
# Allow all users to request standard user certificates
ipa caacl-add all_users_standard_certs
ipa caacl-add-profile all_users_standard_certs --certprofiles=IPA UserCert
ipa caacl-mod all_users_standard_certs --usercat=all
ipa caacl-add-ca all_users_standard_certs --cas=ipa
ipa caacl-enable all_users_standard_certs
# All authenticated users can now request IPA UserCert profile
# No need to explicitly add users or groups
# Profile still restricts certificate type and usageCompliance-Driven Certificate Separation by Geographic Region
Regulatory requirements mandate different CAs for different geographic regions. CA ACLs enforce region-specific certificate issuance aligned with data sovereignty requirements.
# European region uses EU-compliant CA
ipa caacl-add eu_region_certs
ipa caacl-add-profile eu_region_certs --certprofiles=caIPAserviceCert
ipa caacl-add-host eu_region_certs --hostgroups=eu-servers
ipa caacl-add-user eu_region_certs --groups=eu-users
ipa caacl-add-ca eu_region_certs --cas=eu-ca
ipa caacl-enable eu_region_certs
# US region uses US-based CA
ipa caacl-add us_region_certs
ipa caacl-add-profile us_region_certs --certprofiles=caIPAserviceCert
ipa caacl-add-host us_region_certs --hostgroups=us-servers
ipa caacl-add-user us_region_certs --groups=us-users
ipa caacl-add-ca us_region_certs --cas=us-ca
ipa caacl-enable us_region_certs
# Ensures certificates are issued from geographically appropriate CAsSecurity Considerations
Disabled CA ACLs Do Not Enforce Access Control
CA ACLs created with caacl-add are disabled by default until explicitly enabled with caacl-enable. During the period between creation and enablement, the ACL provides no protection, potentially allowing unauthorized certificate requests if administrators incorrectly assume the ACL is active. Disabled ACLs appear in listings but do not enforce policy, creating false security confidence.
Establish procedures requiring immediate enablement after ACL creation and testing. Use configuration management tools to enforce ACL state. Implement monitoring to alert on disabled ACLs that should be active. Regular audits using caacl-find --disabled=True can identify orphaned or forgotten disabled ACLs. Document ACL lifecycle including expected enabled/disabled transitions.
Category Memberships Override Explicit Restrictions
Setting --usercat=all, --hostcat=all, or --servicecat=all grants blanket access to all principals of that type, overriding more restrictive intent. Administrators may add specific users or groups to an ACL and later set category=all, inadvertently granting access to unauthorized principals. Category settings take precedence over explicit membership lists.
Avoid category memberships unless universal access is genuinely required. When categories are necessary, document the business justification and implement compensating controls at the profile or CA level. Use caacl-show --all to verify category settings before enabling ACLs. Implement change control procedures requiring approval for category modifications.
Overlapping CA ACLs Create Unintended Access Paths
Multiple CA ACLs can grant access to the same profile from the same CA for different principal sets. While intentional overlap can support legitimate use cases, unintended overlap creates unauthorized access paths. An overly permissive ACL can negate restrictions in more specific ACLs, granting access to principals that should be denied.
Implement ACL naming conventions clearly indicating scope and purpose. Use caacl-find to identify ACLs granting access to specific profiles or CAs before adding new ACLs. Document ACL interactions and maintain an authorization matrix showing which principals can request which profiles. Regular access reviews should verify ACL combinations align with authorization policies.
Missing CA in CA ACL Prevents All Certificate Requests
CA ACLs must specify at least one CA using caacl-add-ca. ACLs without CA assignments deny all certificate requests regardless of profile and principal matches. This can create operational disruptions when administrators create ACLs but forget to add CA associations, preventing legitimate certificate issuance without obvious error messages.
Implement validation procedures requiring CA verification before enabling ACLs. Use wrapper scripts or configuration management that enforce CA presence. Monitor certificate request denials and correlate with recent ACL changes. The caacl-show command displays CA memberships; verify CAs are listed before enabling new ACLs.
Profile Removal from CA Leaves ACLs Dangling
Deleting certificate profiles from IPA (or removing them from CAs in Dogtag) leaves CA ACLs with references to non-existent profiles. These ACLs cannot grant access but remain in the directory, creating confusion during troubleshooting and potentially masking the need for replacement ACLs with updated profiles.
Implement profile lifecycle management procedures documenting all CA ACLs referencing each profile before deletion. Use caacl-find --certprofiles=ProfileName to identify dependent ACLs. Either update ACLs to reference replacement profiles or delete obsolete ACLs when profiles are retired. Maintain profile-to-ACL mapping documentation for impact analysis.
Service Principal ACLs Without Corresponding Service Entries
CA ACLs can reference service principals that do not exist in IPA using caacl-add-service. This creates authorization gaps where certificate requests using the non-existent service principal are denied despite ACL rules that appear to permit them. The ACL references are not validated at creation time.
Verify service principals exist before adding them to CA ACLs: ipa service-show <principal>. Implement procedures creating service principals before ACL references. Use monitoring to detect certificate request denials for services referenced in ACLs but not present in the directory. Automate service principal creation in conjunction with ACL management.
CA ACL Replication Delays Create Inconsistent Enforcement
In multi-master IPA environments, CA ACL changes replicate asynchronously. During replication lag, different IPA servers enforce different policies, potentially allowing certificate requests on one server while denying identical requests on another. This creates security vulnerabilities during the replication window and inconsistent user experiences.
Implement change management requiring verification of replication status before announcing ACL changes. Use ipa-replica-manage list and replication status checks to confirm propagation. In critical environments, direct certificate requests to specific IPA servers after ACL changes and wait for replication before load balancing. Monitor replication lag and alert on extended delays.
Group Membership Changes Not Reflected in Active Certificates
CA ACLs evaluate group membership at certificate request time. Removing a user from a group does not revoke previously issued certificates, which remain valid until expiration. Former group members retain certificate-based access until certificate expiry, potentially violating separation of duties or least privilege requirements.
Implement certificate lifecycle management tracking group memberships. Use certmonger or scheduled jobs to renew certificates before expiration, allowing ACL re-evaluation. For terminated users or role changes, explicitly revoke certificates using ipa cert-revoke rather than relying on group membership changes. Consider shorter certificate validity periods for roles with frequent membership changes.
All-Powerful Administrator Bypass of CA ACLs
Users with certain administrative privileges can bypass CA ACL enforcement entirely by directly interfacing with Dogtag CA APIs or using IPA framework permissions that override ACL checks. This creates audit and compliance gaps when administrator actions are not subject to the same controls as standard users.
Document which administrative roles can bypass CA ACLs and implement compensating controls including enhanced logging and mandatory code review for direct Dogtag interactions. Use role-based access control to limit the number of administrators with ACL bypass capabilities. Implement separate audit trails for administrative certificate operations.
CA ACL Modification Without Version Control
CA ACLs enforce critical security policies but modifications are often made directly via CLI without version control, change tracking, or rollback capabilities. Unauthorized or mistaken ACL changes can grant excessive privileges or break legitimate access, with no audit trail of who made changes or ability to quickly restore previous state.
Implement infrastructure-as-code approaches to CA ACL management using Ansible, Terraform, or similar tools with Git-based version control. Require pull request reviews for ACL changes. Use IPA’s built-in audit logging combined with SIEM integration to track all ACL modifications. Develop runbooks for emergency ACL rollback procedures.
Certificate Profile Complexity Obscures ACL Intent
Certificate profiles contain complex configurations defining key usage, extended key usage, validity periods, and other parameters. CA ACLs grant access to profiles but administrators may not fully understand profile capabilities, inadvertently granting permissions that violate security policies (e.g., code signing, CA certificate issuance).
Implement mandatory profile documentation describing capabilities, intended use cases, and security implications. Require security review of all profiles before ACL creation. Use profile naming conventions clearly indicating purpose and risk level. Maintain a profile catalog with approval requirements (e.g., high-risk profiles require CISO approval for ACL association).
Testing ACL Changes in Production Risks Availability
CA ACL errors often manifest as certificate request denials, impacting production services. Testing ACL changes in production without proper validation can cause widespread service disruptions when legitimate certificate requests unexpectedly fail, potentially affecting automated renewals for expiring certificates.
Implement non-production IPA environments mirroring production for ACL testing. Use certificate request simulation tools to validate ACL behavior before production deployment. Implement gradual rollouts starting with non-critical services. Maintain emergency rollback procedures and have previous ACL configurations documented for quick restoration.
Wildcard Service Principals in ACLs Create Overly Broad Access
While IPA does not support wildcard matching in CA ACL service memberships directly, administrators might create ACLs with many similar service principals attempting to simulate wildcards. This results in administrative overhead and potential inclusion of unauthorized services when patterns are too broad.
Use specific service principal listings rather than attempting wildcard patterns. For large numbers of similar services, consider grouping services logically and creating separate ACLs per logical group. Implement automation to generate ACL memberships from authoritative service inventories. Regular reviews should verify all listed services still require access.
Sub-CA Certificate Chains Not Distributed to Clients
CA ACLs can direct certificate requests to subordinate CAs, but client systems must trust the complete certificate chain including intermediate CA certificates. If sub-CA certificates are not distributed to clients, certificates issued by sub-CAs will fail validation despite valid ACL configurations and successful issuance.
Implement automated certificate chain distribution to all enrolled systems. Use certmonger and IPA certificate profiles to include chain information in issued certificates. Monitor client certificate validation failures and correlate with sub-CA usage. Provide clear documentation for manual client trust store updates when automated distribution is not available.
Troubleshooting
Certificate Requests Denied Despite Matching CA ACL
Symptom: Certificate requests fail with “Insufficient access rights” or similar errors even though a CA ACL appears to grant the required access. Running ipa caacl-find shows an enabled ACL matching the subject principal, profile, and CA.
Diagnosis: Verify ACL is actually enabled: ipa caacl-show acl-name | grep Enabled. Check if ACL includes all three required components: subject (user/host/service), profile, and CA. Verify group memberships if ACL uses groups: ipa group-show groupname to confirm principal is member. Test if category settings are configured: ipa caacl-show acl-name --all and look for usercat, hostcat, or servicecat.
Resolution: Ensure ACL is enabled: ipa caacl-enable acl-name. Add missing components if ACL is incomplete: ipa caacl-add-ca acl-name --cas=ipa. Verify principal is member of specified groups or add directly to ACL: ipa caacl-add-user acl-name --users=username. Check IPA logs in /var/log/httpd/error_log for detailed denial reasons. Verify CA is actually available: ipa ca-show ca-name.
CA ACL Shows Members But Does Not Grant Access
Symptom: CA ACL contains correct users, profiles, and CAs when viewed with caacl-show, but certificate requests continue to be denied for members listed in the ACL.
Diagnosis: Check ACL enabled status: disabled ACLs appear in listings but do not grant access. Verify no typos in profile or CA names: names are case-sensitive. Test if replication completed: ACL may exist on one server but not others. Check if principal is listed directly or via group: ipa user-show username --all to verify group memberships. Look for conflicting ACLs that might take precedence.
Resolution: Enable the ACL: ipa caacl-enable acl-name. Verify spelling of profile names: ipa certprofile-find to list valid profiles. Force replication and wait for completion: ipa-replica-manage force-sync --from=master.example.com. If using groups, add user directly to test: ipa caacl-add-user acl-name --users=username. Review IPA PKI audit logs in /var/log/pki/pki-tomcat/ca/debug for detailed ACL evaluation.
Changes to CA ACL Not Taking Effect Immediately
Symptom: Modifications to CA ACL using caacl-add-user, caacl-add-profile, or similar commands complete successfully but certificate requests continue to fail as if changes were not made.
Diagnosis: Check replication status across all IPA servers: changes may not have replicated to the server processing the request. Verify which IPA server is handling the request: certificate requests may be load-balanced. Review time of last modification: ipa caacl-show acl-name --all | grep Modified. Check for caching in client tools or intermediate proxies.
Resolution: Wait for replication to complete: ipa-replica-manage list to see all replicas, then check status with ipa-csreplica-manage list. Direct certificate request to specific IPA server for testing: ipa -s specific-server.example.com cert-request. Force immediate replication if needed: ipa-replica-manage force-sync --from=source-server. Clear any client-side caches and retry request. Monitor replication lag and implement alerts for extended delays.
Category Settings Creating Overly Broad Access
Symptom: More users or hosts than intended can request certificates from a CA ACL, despite explicit membership lists being used. Unauthorized principals successfully obtain certificates.
Diagnosis: Check for category settings: ipa caacl-show acl-name --all | grep cat. Look for usercat: all, hostcat: all, or servicecat: all which override explicit membership lists. Review ACL modification history in IPA audit logs. Check if multiple overlapping ACLs exist granting access through different paths.
Resolution: Remove category settings: ipa caacl-mod acl-name --usercat= (empty value removes setting). Add explicit users/groups instead: ipa caacl-add-user acl-name --groups=specific-group. Review all CA ACLs for category usage: ipa caacl-find --all and filter output. Implement change control procedures requiring justification for category settings. Document which ACLs use categories and why.
CA ACL References Non-Existent Certificate Profile
Symptom: CA ACL was created successfully and references a certificate profile, but certificate requests using that profile fail. The profile may have been deleted or never existed.
Diagnosis: Verify profile exists in IPA: ipa certprofile-show profile-name. Check if profile is enabled: disabled profiles cannot be used. List all available profiles: ipa certprofile-find. Review Dogtag certificate profiles: pki-server ca-profile-find to see CA-level profiles. Check if profile was deleted recently in IPA change logs.
Resolution: If profile was deleted, create or import replacement: ipa certprofile-import from XML file. Update ACL to reference correct profile: ipa caacl-remove-profile acl-name --certprofiles=old-profile && ipa caacl-add-profile acl-name --certprofiles=new-profile. If profile should not exist, delete ACL: ipa caacl-del acl-name. Enable profile if disabled: ipa certprofile-mod profile-name --enable. Verify profile is properly imported from Dogtag to IPA if using custom profiles.
Service Principal Not Matching CA ACL Service Members
Symptom: Certificate request for a service principal is denied even though the service appears to be listed in a CA ACL’s service members.
Diagnosis: Verify exact service principal name: ipa service-show service/host.example.com. Check for typos in principal name in ACL: ipa caacl-show acl-name and review service list carefully. Verify service principal exists in IPA: non-existent services in ACL do not grant access. Check if service is member of correct host: service principals are tied to specific hostnames.
Resolution: Add service with exact principal name: ipa caacl-add-service acl-name --services=HTTP/web.example.com. Create service principal if missing: ipa service-add HTTP/web.example.com. Remove incorrectly spelled service from ACL: ipa caacl-remove-service acl-name --services=wrong-name. Use tab completion when adding services to prevent typos. List services with ipa service-find to verify exact names before ACL modifications.
Multiple CA ACLs Causing Conflicting Behaviors
Symptom: Certificate requests have unpredictable results with some requests succeeding and similar requests failing. Multiple CA ACLs exist that reference the same profiles or principals.
Diagnosis: List all CA ACLs: ipa caacl-find --all and identify overlaps. Check which ACLs grant access to the failing profile: ipa caacl-find --certprofiles=ProfileName. Review ACL combinations to understand interaction: a request needs only ONE matching enabled ACL to succeed. Look for disabled ACLs that should be enabled or vice versa.
Resolution: Consolidate overlapping ACLs where possible to simplify administration. Clearly document the purpose of each ACL and intended scope. Use naming conventions indicating ACL scope (e.g., “dept_profile_purpose”). Disable ACLs not currently needed: ipa caacl-disable acl-name. For complex scenarios, create an authorization matrix documenting which principals can use which profiles from which CAs.
CA Not Available for Certificate Requests
Symptom: CA ACL is correctly configured and enabled, but certificate requests fail with “CA is not available” or similar errors about the CA not being accessible.
Diagnosis: Verify CA exists in IPA: ipa ca-show ca-name. Check if CA is enabled: ipa ca-show ca-name | grep Enabled. Verify Dogtag CA subsystem is running: systemctl status pki-tomcatd@pki-tomcat. Review PKI CA logs: /var/log/pki/pki-tomcat/ca/debug for CA availability issues. Test CA connectivity: curl https://ipa.example.com:8443/ca/rest/certs (should return data).
Resolution: Enable CA if disabled: ipa ca-enable ca-name. Restart PKI services if CA subsystem is down: systemctl restart pki-tomcatd@pki-tomcat. For sub-CAs, verify they are properly configured in Dogtag: pki-server ca-show ca-name. Check network connectivity between IPA and Dogtag if they run on separate systems. Review firewall rules allowing access to PKI ports (8080, 8443).
Group Membership Changes Not Reflected in Certificate Access
Symptom: User was added to a group referenced in a CA ACL but still cannot request certificates. Conversely, user removed from group can still request certificates.
Diagnosis: Check current group membership: ipa group-show groupname to verify user is listed. Verify ACL references the group: ipa caacl-show acl-name and check group list. For removals, check if user has an existing certificate that has not expired. Review SSSD cache on client: stale cache may not reflect membership changes.
Resolution: For additions, verify user is in group: ipa group-add-member groupname --users=username. Clear SSSD cache on client: sss_cache -E && systemctl restart sssd. For removals, revoke existing certificates: ipa cert-revoke serial-number --revocation-reason=4 (cessation of operation). Wait for group membership changes to replicate: ipa-replica-manage list and check replication status. Test certificate request from different IPA server if load-balanced.
CA ACL Works for Some Hosts But Not Others
Symptom: Certificate requests from some enrolled hosts succeed while identical requests from other hosts fail, even though all hosts appear to have the same configuration and group memberships.
Diagnosis: Check replication status: different IPA servers may have inconsistent CA ACL configurations. Verify which IPA server each host is using: ipa env server on each host. Check hostgroup memberships: ipa host-show hostname --all to verify group membership. Review network connectivity to IPA servers: some hosts may be unable to reach specific replicas.
Resolution: Force replication to all servers: ipa-replica-manage force-sync --from=master. Verify all replicas have consistent ACL configuration: ipa caacl-show acl-name on each server. Add hosts explicitly to ACL if hostgroup membership is not working: ipa caacl-add-host acl-name --hosts=hostname. Check firewall and network connectivity allowing hosts to reach all IPA replicas. Configure failover behavior in sssd.conf to prefer specific IPA servers.
Profile Shows in ACL But Is Not Enabled
Symptom: CA ACL includes a certificate profile but certificate requests using that profile fail with “profile not enabled” or similar errors.
Diagnosis: Check profile status: ipa certprofile-show profile-name | grep Enabled. Verify profile exists in Dogtag: pki-server ca-profile-find and look for profile name. Check if profile was recently created but not enabled. Review profile configuration in Dogtag: /var/lib/pki/pki-tomcat/ca/profiles/ca/.
Resolution: Enable the profile in IPA: ipa certprofile-mod profile-name --enable. If profile does not exist in Dogtag, import it: create profile XML and use pki-server ca-profile-add. Verify profile enabled in Dogtag: pki ca-profile-show profile-name and enable if needed. Restart PKI services after profile changes: systemctl restart pki-tomcatd@pki-tomcat. Test profile accessibility: attempt certificate request using the profile.
CA ACL Denials Not Logged Clearly
Symptom: Certificate requests are denied but error messages do not clearly indicate which CA ACL rule or component is causing the denial, making troubleshooting difficult.
Diagnosis: Enable IPA debug logging: edit /etc/ipa/server.conf and set debug = True. Review Apache error logs: /var/log/httpd/error_log for detailed IPA framework messages. Check PKI CA debug logs: /var/log/pki/pki-tomcat/ca/debug for Dogtag-level authorization. Use verbose mode in certificate request commands: ipa cert-request --verbose.
Resolution: Temporarily increase logging levels for troubleshooting. Use ipa cert-request with --principal flag to test specific principal: ipa cert-request cert-request.pem --principal=user@REALM. Manually verify each ACL component: confirm principal exists, profile exists and is enabled, CA exists and is enabled, ACL itself is enabled. Use ipa caacl-find with various filters to identify which ACLs might match the request. After troubleshooting, restore normal logging levels to prevent log overflow.
Deleted CA ACL Still Appears to Affect Behavior
Symptom: After deleting a CA ACL with caacl-del, certificate authorization behavior does not change as expected, suggesting the deleted ACL is still active.
Diagnosis: Verify ACL deletion completed: ipa caacl-show acl-name should return “not found”. Check replication status: ACL may be deleted on one server but still exist on others due to replication lag. Review other ACLs that may provide similar access: multiple ACLs can grant the same permissions. Check for cached authorization decisions in IPA framework or Dogtag.
Resolution: Confirm deletion replicated to all servers: ipa caacl-show acl-name on each replica. Force replication if needed: ipa-replica-manage force-sync. Restart IPA services to clear any authorization caches: systemctl restart ipa. Review remaining ACLs: ipa caacl-find to identify other ACLs granting similar access. If behavior is actually correct, identify which remaining ACL is granting access. Clear any client-side caches: kdestroy && kinit to obtain fresh Kerberos credentials.
CA ACL Cannot Be Modified Due to Permission Errors
Symptom: Attempting to modify CA ACL with caacl-mod, caacl-add-user, or similar commands results in “Insufficient access rights” errors even when logged in as admin.
Diagnosis: Verify current user’s permissions: ipa user-show $(ipa env user | awk '{print $2}') --all and check group memberships. Confirm user has CA Administrator role: ipa role-show 'CA Administrator' and verify user or groups. Check if ACL is locked or protected by additional constraints. Review IPA ACI configuration for modifications to default permissions.
Resolution: Add user to appropriate administrative group: ipa group-add-member admins --users=username or add to CA Administrators specifically. Use the IPA admin account for testing: kinit admin and retry command. If using delegated administration, verify the delegated role includes CA ACL modification permissions: ipa role-show role-name. Review custom ACI that may restrict CA ACL modifications. Check for SELinux denials: ausearch -m AVC -ts recent | grep caacl.
Performance Degradation with Large Numbers of CA ACLs
Symptom: Certificate request performance degrades as the number of CA ACLs increases, with request times becoming unacceptably slow.
Diagnosis: Count CA ACLs: ipa caacl-find | grep -c "ACL name". Monitor IPA server performance during certificate requests: CPU and memory usage. Review IPA logs for slow LDAP queries related to ACL evaluation. Check database performance: large numbers of ACL entries can slow LDAP searches.
Resolution: Consolidate ACLs where possible: combine multiple small ACLs with similar purposes. Use category memberships for broad access rather than listing many individual principals. Disable unused ACLs rather than deleting to preserve history: ipa caacl-disable acl-name. Optimize LDAP database indexes for ACL searches: work with directory server tuning. Consider splitting ACL authority across multiple IPA deployments if ACL count is driven by legitimate multi-tenant requirements. Implement caching at application level for frequently requested certificate types.