Which FreeIPA CA setup fits your estate
If you are installing FreeIPA in a regulated environment, the first decision is who signs the certificates it issues. The integrated CA with a self-signed root suits most estates that can run their own certificate infrastructure. It keeps issuance, renewal and revocation inside IdM, and Red Hat's planning guide describes the integrated CA as the option for environments that can run their own certificate infrastructure. The integrated CA signed by an external CA suits organizations whose policy requires a corporate root. In that model, the external CA must allow subordinate CAs, and the external CA's rules on validity periods, subject names and subordinate CAs will limit what IdM can issue. Confirm those constraints with the team that owns the corporate root before you write the install plan.
CA-less suits only rare cases where infrastructure restrictions prevent running a CA at all. It is not a shortcut for avoiding PKI work. In a CA-less install, you request, upload and renew the LDAP, Apache and optional PKINIT certificates manually, each with the full chain of the issuing CA, and certmonger does not track them or warn before they expire. Treat the renewal calendar, chain packaging and expiry alerting as ongoing operational tasks that someone must own. Ask your internal PKI team whether the restriction is a written policy or a preference, because a preference rarely justifies the manual renewal burden.
Whichever model you pick, plan the CA replica count early. Red Hat's guidance suggests two CA servers for most deployments, three or four for very large certificate volumes, and one per region with at least three in total across regions. Losing every server that holds a CA loses the CA configuration with no chance of recovery, so back up deliberately and confirm that your backups cover the CA. Also confirm with Red Hat or the FreeIPA project whether you can switch between a self-signed and an externally signed CA, or add an integrated CA, after installation, because the answer affects how cautiously you commit in the first install.
How the three PKI options compare on issuance, renewal and recovery
This table compares the self-signed integrated CA, the integrated CA signed by an external CA, and a CA-less install across the factors that decide day-to-day certificate work and disaster recovery. Read each row as a question to put to your own PKI team and your external CA before you choose.
| Factor | A: Integrated CA, self-signed root | B: Integrated CA signed by external CA | C: CA-less, external certificates |
|---|---|---|---|
| Certificate issuance | FreeIPA's Dogtag CA issues certificates inside the IdM domain without an outside party in the loop. | Dogtag issues certificates, but its own CA certificate chains to an external root that must allow subordinate CAs. | Certificates for LDAP, Apache and optional PKINIT come from an outside CA with the full chain supplied to IdM. |
| Renewal tracking | certmonger tracks and renews the IdM server certificates automatically. | certmonger tracks the IdM-issued certificates, but the subordinate CA certificate must be renewed through the external CA. | certmonger does not track server certificates or warn before expiry, so you request, upload and renew them manually. |
| Validity and subject name limits | Limited by the policy you set inside IdM. | Certificates may be limited by the external CA's rules on validity periods, subject names and subordinate CAs. Confirm these with the external CA. | Set by the external CA's issuance policy for each certificate. Confirm the allowed names and lifetimes before you request. |
| External dependency | None for day-to-day issuance once installed. | Depends on the external CA for the subordinate CA certificate and any renewal of it. | Depends on the external CA for every server certificate, at every renewal. |
| CA replica planning | Red Hat suggests two CA servers for most deployments, three or four for very large certificate volumes, and one per region with at least three in total across regions. | Same CA replica guidance applies. Each CA server also depends on the external CA's subordinate arrangement. | No CA replicas, since IdM does not run a CA. Plan for the certificate handling on each server instead. |
| Recovery after losing CA servers | Losing every server with a CA loses the CA configuration with no chance of recovery, so keep CA replicas and backups. | The same loss risk applies to the CA configuration. Recovery of the subordinate CA also depends on the external CA's records. | No CA configuration to lose inside IdM, but the external CA and the manually tracked certificates must be recoverable. |
| Change after install | Can be switched to an externally signed CA or extended with an integrated CA after installation. | Can be switched to a self-signed CA or extended after installation, following Red Hat's planning guidance. | Red Hat's guidance covers using a CA-less install only in rare cases, so confirm the path to an integrated CA with Red Hat or FreeIPA documentation before you start. |
How the integrated CA issues and renews certificates
The integrated CA issues certificates for hosts, services and users inside the IdM domain through the Dogtag certificate system that FreeIPA bundles. Whichever root you choose, Dogtag does the signing, tracks what it has issued and publishes revocation data. By default, the first CA server in the topology handles certificate renewal and certificate revocation list publication, so that server carries a role the rest of the topology depends on. Before you install, confirm which server will be first, how it will be backed up, and how the other CA replicas will take over those duties if it is lost. The backup documentation also warns that restoring an outdated backup into an active replica topology can break replication, so restore procedures for CA servers need to be tested, not assumed.
The difference between the two integrated options is the root of trust. With a self-signed root, the CA certificate is generated inside IdM and trusted only where you distribute it, which keeps the chain entirely under your control. With a sub CA signed by an external root, the external CA signs the IdM CA certificate, and the external rules then bind what IdM can issue. Red Hat's planning guide notes that validity periods, subject names and the ability to create subordinate CAs may be limited by the external CA. Before choosing this path, ask the external CA's operator whether it permits sub CAs, what maximum validity it allows, which subject name patterns it accepts, and how renewal of the sub CA certificate will be handled, since that renewal is outside IdM's control.
Plan for a change in the root choice before you need one. Red Hat's planning guide states that you can switch between a self-signed and an externally signed CA or add an integrated CA after installation, but the switch is an operational project with its own testing and client trust updates, so confirm the exact procedure for your version with the vendor documentation and a lab rebuild. Make a written record of the CA configuration and key material, store it outside the IdM servers, and rehearse a restore. Red Hat warns that losing every server holding the CA loses its configuration with no chance of recovery, and that is the risk the backup and replica plan must cover.
How many CA replicas to run and why losing them matters
The CA configuration lives on the servers that run the certificate authority, so replica count is a recovery decision as much as a capacity one. The cards below cover the loss risk, the count guidance, the per-datacenter rule and the backup cautions that apply to any of the three certificate setups.
Losing every CA server is unrecoverable
If every server holding the CA is lost, the CA configuration is lost with it, and there is no chance of recovery. This applies to the integrated CA in either its self-signed or externally signed form. Before you install, confirm which servers will hold the CA role, how each one is protected, and what the restore path is if all of them fail at once.
Two CA servers for most deployments
Red Hat's planning guidance suggests two CA servers for most deployments, so that losing one does not leave the CA without a working copy. Two servers do not protect against a shared failure such as a bad change applied to both, so pair the count with tested backups. Confirm the count against your own certificate volume and change process.
Three or four for large volumes
Where certificate issuance volume is very large, Red Hat's guidance moves the count to three or four CA servers. Higher volume raises the load on the CA and the number of renewals it handles, so a larger group spreads that work. Ask your team to estimate issuance volume from the hosts, services and certificate lifetimes you plan to run before settling on a count.
One CA per region, three in total
For a deployment spread across regions, Red Hat's guidance is one CA server per region with at least three in total across regions. This keeps issuance local to each region while preserving enough copies to survive a single loss. Check whether your regions have the network paths and the operational staff to run a CA server in each one.
PKI replica in every datacenter
The FreeIPA deployment recommendations advise at least one replica per datacenter running PKI where PKI is used, alongside two to three replicas per datacenter overall. Keep no more than four replication agreements per replica, so the topology stays manageable as it grows. Map each datacenter to its PKI replica before you decide which integrated CA option fits.
Outdated backups can break replication
FreeIPA's backup documentation warns that restoring an outdated backup into an active replica topology can break replication. The first server also handles certificate renewal and CRL publication by default, so a restore must account for that role. Test ipa-backup and ipa-restore in a non-production topology, and confirm which server will take over renewal and CRL duties after a recovery.
What a CA-less install asks of your team each renewal cycle
This sequence shows the certificate work your team must own when FreeIPA runs without its own CA, from identifying each server certificate to confirming the renewed chain is in place before the old one expires.
Inventory every server certificate IdM needs
Your identity or PKI owner lists each certificate the CA-less IdM server depends on: the LDAP server certificate, the Apache web server certificate and, if you use smart card or PKINIT authentication, the PKINIT certificate. Record which host carries each one, which service uses it and where the private key is stored. Done means every certificate has a named owner and a location recorded in your own inventory, because IdM will not warn you about any of them.
Request certificates from the outside CA
Your team submits a certificate signing request for each identified service to the external CA, following that CA's own enrollment process. Confirm with the outside CA that it will issue server certificates for these names and that it supports the key types IdM uses. Done means each request has been approved and you hold the issued certificate for each service.
Assemble the full chain for each certificate
For each issued certificate, build a file that contains the server certificate together with the full chain up to the issuing CA. IdM needs the complete chain for the LDAP server, the Apache server and any PKINIT certificate, so an intermediate that is missing from the bundle will cause that service to fail its checks. Done means each chain file opens cleanly and each intermediate and root appears in the expected order.
Confirm self-signed certificates are not in use
Check each server certificate for a self-signed issuer. Red Hat's guide for installing IdM without a CA states that self-signed third-party server certificates cannot be used, so any certificate that trusts only itself must be replaced before installation or renewal proceeds. Done means every certificate in the inventory traces back to an outside CA through its full chain.
Upload and apply the certificates on each server
On each IdM server, your administrator places the chain files and private keys where the LDAP and Apache services expect them, then restarts or reloads those services under your change process. The team tests a login through Kerberos, a web UI session and any PKINIT path you rely on. Done means each service presents the new chain and the authentication tests pass on every replica that serves that role.
Track expiry dates outside IdM
Because certmonger does not track the server certificates in a CA-less install, your team records each certificate's expiry date in a calendar, monitoring tool or ticketing system and assigns an owner to each date. Confirm that the alert reaches a person who can act on it, and test the alert before relying on it. Done means every certificate has a documented expiry date and a reminder that is independent of IdM.
Renew and redeploy before expiry
When a reminder fires, your team repeats the request, chain assembly and upload steps with the outside CA, then applies the renewed certificates to each server. Your change record should show who approved the renewal and which hosts were updated. Done means the renewed certificates are live on every server and the old ones are archived, with the next expiry date recorded.
Which option fits which environment
A single-site lab or internal estate usually fits the integrated CA with a self-signed root. The FreeIPA deployment recommendations describe this as FreeIPA running its own PKI with a self-signed CA certificate, and Red Hat's planning guide says the integrated CA suits environments that can run their own certificate infrastructure. Your clients and services then trust one internal root, and you keep control of issuance without a dependency on an outside CA.
- Operational simplicity: Certificate issuance, renewal and CRL publication happen inside IdM, with certmonger tracking the server certificates.
- Switching later: Red Hat's planning guide says you can switch between a self-signed and externally signed CA or add an integrated CA after installation, so a lab can start simple.
- Replica count: Even a small site needs a CA replica plan, because losing every server with a CA loses the CA configuration with no chance of recovery.
- Condition that changes the answer: If you must chain to a corporate root that auditors or browsers already trust, the externally signed integrated CA becomes the better fit.
- Trust distribution: Confirm that every client, application and browser you care about can import the self-signed root through your configuration management.
Before installing, confirm the root's validity period and key size with your security team, and decide how many CA servers the site will run.
A multi-datacenter or multi-region estate usually fits an integrated CA, with the root either self-signed or signed by an external CA, and CA replicas placed deliberately across sites. The FreeIPA deployment recommendations advise at least one replica per datacenter running PKI or DNS where those services are used, and Red Hat suggests two CA servers for most deployments and one per region with at least three in total across regions. The CA-less option rarely fits this shape because renewal stays manual.
- Replica placement: Run PKI on at least one replica in each datacenter that uses it, and keep the total number of replication agreements per replica within the recommended limit.
- Volume: Red Hat's guidance adds servers for very large certificate volumes, so estimate issuance load before fixing the count.
- Failure domains: Losing a datacenter should not remove the last CA server, so spread CA replicas across sites.
- Backups: FreeIPA's backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so plan restores with the topology in mind.
- Condition that changes the answer: If one region has no permitted route to other CA servers, a regional CA design needs its own root and trust plan.
Ask your architect to document which server renews certificates and publishes the CRL by default, and which replica takes over if it fails.
An estate whose external CA policy restricts subject names, validity periods or subordinate CAs usually fits the integrated CA signed by that external CA, provided the external CA allows subordinate CAs. Red Hat's planning guide warns that certificates issued in the IdM domain may be limited by the external CA's rules on validity, subject names and subordinate CAs. If the external CA will not sign a subordinate CA at all, the CA-less option becomes the realistic path, with manual renewal of each server certificate.
- Subordinate CA permission: The FreeIPA deployment recommendations list the requirement that the external CA must allow sub CAs for the externally signed option.
- Validity limits: Certificates issued inside IdM can be no longer than your policy allows, which affects how often renewal happens.
- Subject names: Confirm the naming pattern for hosts, services and users before enrolling clients, because the external CA may reject names IdM would otherwise generate.
- CA-less cost: Certificates for LDAP, Apache and optionally PKINIT must be requested, uploaded and renewed outside IdM, with the full chain, and self-signed third-party certificates cannot be used.
- Condition that changes the answer: A policy that forbids subordinate CAs and requires per-host certificates from a central team points to CA-less.
Confirm with the external CA or security team the subordinate CA permission, maximum validity, allowed subject name format, revocation method and who approves each renewal.
Can you change the CA setup after FreeIPA is installed?
Yes, according to Red Hat's Identity Management planning guide, you can switch between a self-signed and an externally signed integrated CA, or add an integrated CA after installation. Treat that as a documented option, not a routine change. The exact procedure, its prerequisites and its side effects depend on your installed version, so confirm them against the Red Hat planning guide for CA services and the FreeIPA documentation for that release before you schedule any change.
The external CA's rules still apply after the move. If you move to a CA certificate signed by an outside authority, that authority must permit subordinate CAs, and it can limit validity periods, subject names and further subordinate CAs for every certificate IdM issues afterward. Confirm those constraints with the external CA before you start, because they shape the certificates your hosts and services will receive. Certificates already issued under the old root do not change on their own, so plan how trust will be distributed to clients during the transition.
Reissuing certificates and coordinating replicas are where most of the work sits. Check which servers hold the CA role, which one handles renewal and CRL publication by default, and whether your backups would restore an outdated CA state. Schedule the change with all CA replicas in view, and avoid restoring an older backup into an active topology while the change is in progress, since the FreeIPA backup documentation warns that this can break replication. Test the procedure in a non-production copy first and record the result.
How the CA choice changes upgrades, backups and monitoring
Who renews and monitors certificates with an integrated CA versus a CA-less install?
With the integrated CA, FreeIPA manages issuance and renewal of the certificates it issues inside the IdM domain, and the first server handles certificate renewal and CRL publication by default. In a CA-less install, you request, upload and renew the server certificates yourself, outside IdM. Red Hat's planning guide states that certmonger does not track those server certificates or warn before they expire, so your team must own the expiry calendar and the renewal runbook. Ask your vendor or internal PKI team who owns each certificate and how expiry alerts reach them.
Does an externally signed integrated CA still renew automatically?
Yes, the integrated CA continues to run inside IdM, but its signing certificate comes from your external CA. Red Hat's planning guide notes that certificates issued in the IdM domain may be limited by the external CA's rules on validity periods, subject names and subordinate CAs. That means the external CA's policy, not only FreeIPA's settings, determines how long certificates last and what they can contain. Confirm the external CA permits subordinate CAs and agree its renewal process before installation.
How do backups interact with CA servers in FreeIPA?
FreeIPA provides ipa-backup and ipa-restore, with full backups or online data-only backups. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so restore procedures must be planned around the whole topology. Red Hat's planning guide also warns that losing every server with a CA loses the CA configuration with no chance of recovery. Keep CA replicas count in mind: the guide suggests two CA servers for most deployments, and your backup scope and restore runbook should cover every CA server.
What changes during a FreeIPA upgrade with each CA option?
The CA option decides what you must verify before and after an upgrade. With an integrated CA, check the CA services, the first server's role in renewal and CRL publication, and replication health on every CA server. With a CA-less install, the upgrade itself does not renew your certificates, so confirm expiry dates and the full chain for LDAP, Apache and PKINIT before and after the change. FreeIPA 4.13.4 fixed two CVEs, which is a reason to plan a current patch level, and your vendor should confirm the upgrade path for your release.
Can I switch between CA options after the install?
Red Hat's planning guide says you can switch between a self-signed and an externally signed CA, or add an integrated CA after installation. A CA-less install is the exception to plan for: it is intended for rare cases where infrastructure restrictions prevent a CA, so moving to an integrated CA later is a planned project, not a configuration toggle. Ask whether your specific IdM version and topology support the switch, and what testing and rollback steps the change requires.
What skills does an operator need for each CA option?
An integrated CA needs operators who understand PKI basics, replica topology, CA server roles, and how the first server handles renewal and CRL publication. An externally signed CA adds the ability to work with the external CA's policy on validity, subject names and subordinate CAs. A CA-less install needs certificate lifecycle skills for manual request, upload and renewal, plus the discipline to monitor expiry without help from certmonger. Ask for training or handover documentation in the quote if your team lacks these skills.
How many CA replicas should I run, and what does it cost to run them?
Red Hat's planning guide suggests two CA servers for most deployments, three or four for very large certificate volumes, and one per region with at least three in total across regions. The FreeIPA deployment recommendations advise at least one replica per datacenter running PKI where PKI is used, and no more than four replication agreements per replica. Each extra server adds infrastructure, monitoring and backup scope, so cost depends on your hosting model and the staff time to run it. Ask your team or implementation partner to quote hosting, monitoring and backup work per server.
How DeployOpen scopes and delivers FreeIPA PKI work
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the CA model is chosen against your certificate policy and then built and handed over in your environment. Engagements are fixed-scope, with the scope agreed in writing before work starts.
How we scope
- Record which CA model you need: self-signed integrated CA, externally signed integrated CA, or CA-less.
- Confirm with your external CA whether it permits subordinate CAs and what validity, subject name and naming rules it applies.
- Agree in writing the number of CA replicas, their datacenter placement and the server roles each one holds.
How we build
- Install and configure FreeIPA with the chosen PKI model, then test certificate issuance for hosts and services.
- For CA-less builds, set up the certificate requests, chain uploads and renewal steps needed for LDAP, Apache and PKINIT certificates.
- Document renewal ownership, the first-server role for renewal and CRL publication, and the backup procedure for each CA server.
How we hand over
- Deliver the written configuration, replica topology and certificate inventory, with each certificate's owner and expiry date recorded.
- Run a restore exercise from ipa-backup output so your team has tested the recovery path before go-live.
- Walk your operators through issuance, renewal and the steps to switch CA models later, as the written scope defines.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, separate from the fixed-scope build.
- Retainers can cover certificate renewal tracking and FreeIPA release upgrades on the schedule your team agrees.
- Confirm in the quote which renewal and monitoring tasks sit inside the retainer and which remain with your own staff.
