FreeIPA CA ACLs for certificate issuance

How FreeIPA CA ACLs decide who gets which certificate

CA ACLs are the FreeIPA rules that tie a certificate profile, a requesting principal and an issuing CA together, so that a certificate request is allowed only when all three match an entry. A regulated team that runs FreeIPA as its internal certificate authority for hosts, services and users needs these rules because the default posture is broader than most compliance owners expect. Without them, any principal permitted to request a certificate through the CA can ask for certificates under profiles the team never intended to offer. Teams usually need CA ACLs once they have more than one class of certificate, such as service TLS, user authentication and device certificates, or once a separate group owns each class.

CA ACLs do not replace the other permission layers in FreeIPA. Host-based permissions decide which hosts may request certificates for their own names, and service-level permissions decide which principals may manage a given service principal. Role-based access control and delegation rules decide who may administer the CA and its profiles. Before you write any CA ACL, list the certificate classes, the principals that request each class, and the issuing CA each class should come from. Confirm the exact ACL object types, default ACL behavior and the matching rules for your FreeIPA version in the official documentation, because those details change between 4.x releases and should be tested in a non-production realm before you rely on them.

Which CA ACL pattern fits which issuance policy

This table compares common FreeIPA CA ACL patterns by the issuance policy each one serves, the risk it carries and what to review in it. Read each row as a pairing of a policy goal with the object scope that keeps it narrow. The main takeaway is that every pattern is only as tight as the principals, profiles and CAs it names, so review those three objects first.

Pattern	When it fits	What it risks	What to review
Per-host-group service certificates	Servers in a host group need TLS certificates from the ipa CA for a defined set of service principals and profile.	A broad host group or wildcard service principal lets hosts request certificates for names they do not own.	Membership of the host group, the service principals allowed, and whether the profile is the service certificate profile.
Per-user certificates for a specific profile	A user group needs one certificate type, such as client authentication or S/MIME, and nothing else.	A user group that includes more people than intended can request certificates under a profile meant for a small population.	User group membership, the single profile named in the rule, and any change to the profile's extensions or validity.
Sub-CA issuance restricted to a device group	Devices in a managed group, such as VPN or Wi-Fi endpoints, need certificates from a lightweight sub-CA that signs only for them.	Hosts outside the intended group, or a sub-CA ACL that names no profile, can obtain device certificates from the sub-CA.	Device group membership, the issuing sub-CA named in the rule, and the profile list, since disabling the sub-CA is the broadest response if the scope is wrong.
Narrowly held admin bypass	A small set of trained administrators must issue certificates outside normal rules for a documented exception, such as recovery work.	Admin rights bypass the scoped rules, so a compromised admin account can issue any certificate from any CA.	Who holds the permission, whether it is used only through a logged change process, and audit logs of every issuance it covered.
Principal-scoped rules for individual hosts	One named host needs a specific certificate that does not fit any group, and the exception must be visible in review.	Individual rules multiply over time and become hard to read, and stale host names remain after the host is retired.	Each named host still exists, the rule's purpose is recorded, and the rule is removed or justified at each review.
Deny-by-default with no broad allow	Not a pattern to grant access but the baseline. Certificates are issued only where a rule names the principal, profile and CA.	Teams may add a permissive rule to unblock an urgent request and forget to narrow it afterward.	Any rule that lists all hosts, all users or all profiles, and any change made outside the normal review path.
Shared service principals across hosts	Several hosts run the same service and need one certificate identity under a common rule.	A single shared principal can be requested from any host that the rule covers, which weakens the link between certificate and machine.	Which hosts can request the shared principal, and whether each host should have its own service principal instead.

Setting up CA ACLs in an existing FreeIPA deployment

This sequence replaces broad issuance rules with narrow, tested CA ACLs, so each certificate profile and issuing CA is available only to the principals that need it. It ends with a documented set of allowed and denied test requests and a reviewed list of default access that remains.

Inventory profiles, issuing CAs and existing ACLs
The platform owner lists every certificate profile in use, every CA that issues certificates, and every CA ACL already defined, using ipa certprofile-find, ipa ca-find and ipa caacl-find. For each certificate in use, record the profile, the issuing CA and the principals that request it today. The step is done when this inventory accounts for the certificates your teams actually request, which you can cross-check with ipa cert-find.
Define requesting principals for each use case
Work with each service owner to map every certificate use case to the specific hosts, host groups, service principals or user groups that should request it. Record the profile, the issuing CA and the approver for each use case. Avoid mapping any use case to all hosts or all users. The step is done when every use case has one named owner and a written principal list. For sub-CA and profile setup, see the topics on lightweight sub-CAs and certificate profiles.
Create the narrowest ACL for each use case
Create one CA ACL per use case with ipa caacl-add. Attach the profile with ipa caacl-add-profile, attach the issuing CA with ipa caacl-add-ca when the ACL should be limited to a sub-CA, and add principals with ipa caacl-add-host, ipa caacl-add-service or ipa caacl-add-user, or their group equivalents. Start with named hosts or groups. Check each ACL with ipa caacl-show NAME --all and confirm it lists exactly the profile, CA and principals you planned.
Test with real requests from allowed and denied principals
From a host or user that the ACL should allow, generate a CSR and submit it with ipa cert-request against the intended profile, then confirm the certificate issues. Next, submit the same kind of request from a representative principal that should be refused, such as a host outside the group or a user without membership. The step is done when the allowed request succeeds, the denied request returns an access error, and both results are recorded in your change file.
Confirm the admin bypass behavior
Determine whether the admin account and members of administrative groups can request certificates outside the ACLs you have defined. Test this with a non-admin account and with an admin account against a profile that the ACLs restrict, then document the result for the FreeIPA version you run. Review the membership of administrative groups and remove anyone who does not need it. The step is done when the test results and the reviewed membership list are on file.
Remove broad default access after testing
After every planned use case passes its tests, review the default ACLs that grant hosts and services access to the service certificate profile. Disable any default rule that covers principals you did not approve, using ipa caacl-disable first so you can observe the effect before deleting it. Then repeat the allowed and denied requests from the previous step. The step is done when the same tests pass and ipa caacl-find shows no ACL that matches more principals than you approved.

Risks that come from loose certificate issuance rules

CA ACLs decide which identities can obtain which certificates, so a rule that is too broad, too stale or too easy to bypass can issue certificates nobody meant to issue. The cards below cover the failure patterns we see most often and the control that addresses each one. Renewal permissions deserve equal attention, because they decide whether certificates keep working.

Over-broad principal groups

A CA ACL that grants a whole user group or host group access to a profile lets every member request certificates for any principal the rule allows. Group membership tends to grow over time through unrelated onboarding, so the effective population drifts away from what the rule author intended. Check each ACL's member groups against the people and hosts who actually need that certificate type, and narrow the rule to specific host groups or service principals where possible.

Orphaned ACLs after host retirement

When a server is decommissioned, its host entry and service principals may be removed while the CA ACLs that referenced them remain. Stale rules are hard to spot in an audit because they do not fail visibly, and a reused hostname could inherit the old permission. Make host retirement a checklist step that searches existing ACLs for the retired principal and removes or updates the rule before the host record is deleted.

Admin bypass used for routine work

Administrators with the permission to request certificates without ACL evaluation can issue anything, which is useful during recovery but dangerous as a daily habit. Routine use of that bypass hides the real access model, since issuance no longer appears to depend on any rule. Limit the permission to a small named group, and review its audit trail for requests that no ticket or change record explains.

Renewal depending on access rights

Certificate renewal runs through the identity and CA infrastructure, and a principal that loses its issuance right may fail to renew a certificate it already holds. The first server handles certificate renewal and CRL publication by default, so a change to that server or its permissions can stop renewals across the deployment. Before recovery planning, confirm which server is the renewal master, which principals renew which certificates, and that those principals keep the rights they need.

ACLs that no one reviews

CA ACLs are created during build and then rarely revisited, so their purpose and owner are often unknown by the next audit. Without a named owner and a review record, an auditor cannot tell whether a rule is still justified. Assign each profile and ACL an owner, record the business reason, and export the current rule set on a schedule so changes can be compared over time.

How to review CA ACLs during an audit

An auditor assessing certificate issuance controls wants to know who could obtain which certificates, whether that access was approved, and whether issuance matched the policy in practice. Independent auditors assess these controls and decide what is sufficient. DeployOpen prepares the evidence so that the answers can be traced back to the running system.

Current ACL inventory: a complete list of CA ACLs, with the certificate profiles, principals (users, groups, hosts and services) and issuing CAs each one covers.
Change history: records showing when each ACL was created, modified or removed, and who approved the change.
Issuance sample: a selected set of issued and denied requests, with the requester, profile, CA and timestamp.
Admin bypass review: a list of who holds the permission that lets an administrator issue certificates outside the normal ACLs, and why.
Scope statement: a written description of which CAs and profiles the review covers, so the auditor knows what was and was not examined.

Confirm with the auditor which period, sample size and format they expect before you export anything, and agree in advance how they will receive personal data about requesters.

The security engineer produces the evidence from the FreeIPA servers and must be able to show that the export is complete and unaltered. The export should be repeatable, so a second person can run it later and get comparable output. Run it against a replica that is in sync with the renewal master, and record which server was queried.

Scripted ACL export: use the ipa caacl-find command with --all to dump every CA ACL, and save the output with the date and the server name.
Profile and CA references: export the certificate profiles and sub-CA definitions that the ACLs reference, so every ACL can be read on its own.
Directory state: capture the group and host membership that the ACLs depend on, because an ACL's effect changes when membership changes.
Log extraction: pull the relevant entries from the Dogtag CA and FreeIPA logs for the sample period, and keep the original files alongside the extracts.
Integrity record: store a checksum for each export and record who ran it.

Confirm that the export command and log locations match your FreeIPA version, because output fields and log paths can change between 4.x releases.

Limits to confirm in your own environment

CA ACL behavior is version-specific, and the details that decide who gets which certificate sit at the edges: matching rules, bypass permissions, service principals and logging. Confirm each item against the release documentation for the FreeIPA version you run, and test it on a non-production server before you rely on it.

Exact ACL matching behavior

Confirm how your version evaluates a CA ACL when several rules could match the same request. Check whether a rule matches on the profile, the requesting principal, the target host or service, and the issuing CA, and whether a missing attribute in one rule widens or narrows the match. Build a small test matrix of allowed and denied requests and run it against your own servers rather than assuming the documented intent holds for your build.

Admin bypass grant and logging

Find out which permission lets an administrator request a certificate outside CA ACL restrictions, which role or privilege holds it by default, and whether your version records its use distinctly from normal issuance. Treat this as the highest-risk permission in the design. Ask who holds it, whether the membership is reviewed, and whether a bypassed request leaves a record that an auditor can separate from routine issuance.

Service principals and host enrollment

Test how CA ACLs apply to service principals created for web and LDAP services and to hosts enrolled as clients. Confirm whether a host-bound request is checked against host or hostgroup membership, whether a service principal can be granted a certificate for a name it does not own, and how the answer changes after a host is re-enrolled or removed. Changes to host membership can alter issuance without any change to the ACL itself.

ACL changes in audit logs

Confirm what your version writes to the audit log when a CA ACL is created, changed, disabled or deleted, and what it writes when a certificate is issued under an ACL. Check whether the log identifies the rule, the actor and the time, and whether it can be shipped to your central log store. An ACL change that leaves no trace makes later access reviews unreliable, so test one change end to end before you depend on the record.

Renewal and existing certificates

Confirm whether tightening or removing a CA ACL affects certificates already issued and tracked by certmonger, and whether renewal is checked against the current ACL or the one in force at original issuance. Plan for the case where a renewal fails after a policy change, because an outage caused by an authorization tightening is harder to diagnose than an expired certificate. Verify this behavior on your version with a test certificate.

Upgrade and replica consistency

Check that CA ACL rules and their evaluation behave the same on every replica and after moving between 4.x releases. Confirm that the ACL configuration replicates correctly and that a mixed-version topology during a rolling upgrade does not change which requests are approved. Read the release notes for each version in your upgrade path, and run the same test matrix on each replica before you return it to service.

Questions teams ask before changing CA ACLs

What does a CA ACL review or change cost?

The cost follows the written scope, and no price list exists. The main drivers are the number of certificate profiles, the number of issuing CAs (the main ipa CA and any sub-CAs), the number of principal groups that need entitlements, and how much evidence the audit requires. Each added profile or group means another rule to design, test and document. Most engagements are fixed-scope, so the quote should list the profiles, CAs and groups in scope, the test cases, and the deliverables such as the ACL inventory and change records. Ask whether the quote covers only the design, the implementation, or an audit-ready review, and whether a retainer for later changes is included.

How long does changing FreeIPA CA ACLs take?

Duration depends mostly on how many profiles and principal groups need to change and how well the current rules are understood. A small, well-documented environment with a few profiles moves faster than a deployment where ACLs were added over several years without records. Testing usually takes as long as the design, because each rule should be checked by requesting a certificate as a representative principal and confirming the result. Your change windows, approval cycles and the time your owners need to confirm group membership also set the pace. Ask for a timeline tied to the agreed scope and milestones rather than a general estimate.

What must our internal team provide before an ACL project starts?

Your team needs to provide administrative access to the FreeIPA deployment, a non-production environment or a test window for validation, and a current export of the existing CA ACLs, profiles and group memberships. Each principal group and each profile should have a named business owner who can confirm who should receive which certificate. Change windows must be agreed in advance because some changes affect certificate issuance for live services. Ask your engagement partner to list these inputs in the written scope so gaps are visible before work starts.

Can our own team change CA ACLs without a partner?

Yes, a capable FreeIPA administrator can change CA ACLs with the ipa command-line tools and the web UI, provided the team has a clear inventory of who should receive which certificate. The harder part is the review: confirming that no principal holds broader rights than intended, that the admin bypass permission is limited, and that each decision is recorded for an auditor. Teams with a small number of profiles and CAs often manage this in-house. Teams with many profiles, several sub-CAs or a pending audit often bring in outside help for the design and evidence. Test changes in a non-production environment first, because an incorrect ACL can block a service from renewing its certificate.

What does a fixed-scope ACL engagement include?

A fixed-scope engagement covers a written list of work agreed before it starts. For CA ACLs this typically includes an inventory of current profiles, CAs, principal groups and ACL rules, a target design that states who may request which certificate from which CA, the configuration changes for that design, validation tests, and a document describing the final state and the review procedure. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications. An independent auditor performs that assessment. Ongoing reviews after go-live can be covered by a retainer.

Which parts of CA ACL work affect audits most?

Auditors usually look for evidence that issuance rights follow an approved policy, that privileged bypass rights are limited and reviewed, and that changes are recorded. In practice this means keeping a current list of every ACL with its owner, the profile it covers, the CA it applies to, and the groups or hosts it names. The admin bypass permission should be listed separately with its holders and a review date. Ask your compliance lead which control IDs and evidence formats they expect before the design is fixed, and confirm the requirements directly with your assessor, since the mapping depends on your framework.

How do we test a CA ACL change before it goes live?

Test each rule with representative principals in a non-production FreeIPA environment. For every profile and CA, request a certificate as a user or host that should be allowed and confirm the issuance succeeds, then repeat with a principal that should be denied and confirm the request is refused. Include service principals used by certmonger for automatic renewal, because a rule that blocks renewal causes outages later rather than at deployment. Record the results and keep them with the change record. Ask the team to test the admin bypass separately so that its scope is confirmed rather than assumed.

Where the FreeIPA release and design docs fit in

Before you write a CA ACL, confirm which FreeIPA release your servers run and read the release notes for that version. The 4.13.4 release notes list a stabilization release dated July 9, 2026, which fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, and hardened authentication checks across the API. If your servers are older than that release, the security fixes are a reason to plan an upgrade before you tune certificate authorization, not after. Check the version on every server, because replicas in one topology can drift, and record the result in your change file alongside the ACL export you review.

Behavior changes between 4.x releases, so the same ACL definition can produce different results on different versions. The 4.13.0 release notes, for example, introduced random certificate serial numbers by default and other changes that affect certificate handling. Read the release notes for every version between your current release and your target, and test ACL changes on a non-production deployment at the target version. The FreeIPA design pages describe how the components fit together, but they do not replace the release notes for the behavior of your specific build, so treat them as background for why a control works the way it does.

Confirm the exact ACL behavior with the official documentation and your own tests before you sign off on a policy. Ask your platform team to record the FreeIPA version, the release notes reviewed, and the output of your certificate ACL review in the same change record. Auditors will ask how you knew the authorization rules matched the intended design at the time of issuance, and a versioned record of the release notes you relied on answers that question directly.

How DeployOpen works on this

DeployOpen plans, implements and documents FreeIPA CA ACLs as part of a self-hosted FreeIPA deployment inside your own infrastructure. The work starts with a written inventory of which certificates your services need and which principals and issuing CAs should be allowed to request them.

How we scope

Inventory every certificate type your services, hosts and users need from FreeIPA today
Map each certificate profile to the principals, host groups and services allowed to request it
Agree in writing which issuing CAs, sub-CAs and admin bypass rights are in scope

How we build

Create CA ACLs that name profiles, principals and issuing CAs, with groups instead of individual accounts
Restrict or document the admin bypass permission so it is used only under a recorded procedure
Test each ACL with requests that should succeed and requests that should be denied before go-live

How we hand over

Deliver the ACL inventory, the design rationale and the test cases with expected results
Provide a review procedure that lists CA ACLs, owners and last review dates for auditors
Train your administrators on adding, changing and retiring CA ACLs without breaking renewals

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
Ongoing support, upgrades and periodic ACL reviews are available as a retainer
Ask any partner for the written scope and confirm how changes to an agreed scope are priced and approved