How many FreeIPA servers should run the CA

How many FreeIPA servers should run the CA in your deployment?

If you are placing FreeIPA replicas, put at least one CA-capable replica in every datacenter that uses PKI, then set the total by how many server losses you need to survive and by where the renewal and CRL roles sit. The number is a design decision, not a fixed count. The FreeIPA deployment recommendations set the floor: at least two to three replicas in each datacenter, and at least one replica per datacenter running PKI or DNS if you use those services. Treat that floor as the minimum for a site, not as a complete answer for your estate.

Start by asking which datacenters need certificate issuance locally. If a site must keep issuing and renewing service certificates when its WAN link or the primary site is down, it needs its own CA-capable replica there. Next, count failure tolerance. A single CA server is a single point of failure for issuance, renewal and revocation, and a lost CA replica without a second one nearby leaves you rebuilding trust under pressure. Check also that the topology keeps enough replication agreements per replica, since the recommendations cap that at four, so a larger CA group still has to be wired as a connected mesh that does not depend on one server.

Confirm three things before you commit to a layout. First, which server holds the CA renewal and CRL publisher role, because the backup documentation notes that the first server handles certificate renewal and CRL publication by default, and restoring an outdated backup into an active topology can break replication. Second, whether any site uses a hardware security module for CA keys, since that changes how a replacement server is provisioned. Third, how your auditors expect certificate issuance to be controlled and logged. Ask your implementation partner to put these answers in the written scope, and read the FreeIPA deployment recommendations against your own site list before you fix the count.

Which CA layouts fit which deployments

This table compares four ways to place the certificate authority across FreeIPA replicas. Read each row as a trade-off between how many CA copies must replicate and how many systems your team must patch, back up and monitor. The main takeaway is that two to three replicas per datacenter sets the production baseline, and a single CA server is a single point of failure.

Layout	When it fits	Replication and operations cost	Confirm before choosing
One CA server	Lab or proof of concept where certificate service can stop for a while	Least CA replication. Losing that server stops renewals and CRL publication until it is recovered.	Recovery steps for the CA and renewal role in your version's Red Hat documentation
One CA replica per datacenter	Meets the minimum PKI floor where each site needs a CA-capable server	Few CA copies to replicate. Each site depends on one CA server for its local certificate work.	Which replica holds renewal and CRL roles, and how to move them safely
Two or three CA replicas per datacenter	Production sites that must keep certificate service through one server outage	Matches the recommended replica count per datacenter. Adds replication, patching and monitoring at each site.	The CA replica count your version supports and the replication agreement limits per server
CA on every replica	Small topologies where all servers are local and identical in role	Most CA copies and the heaviest certificate replication. Every server becomes a PKI system to maintain.	Whether your version supports this layout and what it changes in replication topology
Restore discipline across CA servers	Any layout with more than one CA server	Restoring an outdated backup into a live topology can break replication, so every CA server needs one tested routine.	The restore procedure and its order of steps in your version's backup documentation

What the CA role holds and why it shapes the layout

The CA count question starts with what a CA replica actually does in a FreeIPA deployment. FreeIPA issues certificates from an integrated Dogtag certificate authority, and that CA runs on the servers you assign the CA role to. Each CA replica takes part in the same multi-master directory that holds users, groups, hosts and policies, so a CA role is a decision about which servers serve certificate requests and which hold the CA's own data. Before you choose a number, confirm in your deployed version which CA data is replicated to every CA-enabled server and which data stays on a single host, since the answer determines how much a lost CA server costs you.

The first server in a deployment holds two roles by default: certificate renewal and CRL publication. The FreeIPA backup documentation states that the first server handles these tasks by default, and it warns that restoring an outdated backup into an active replica topology can break replication. This means the renewal master is not chosen by how many CA servers you run. Adding a second or third CA replica does not move renewal or CRL publishing to those servers, so a layout with several CA replicas can still depend on one host for the work that keeps shared certificates current. Check which server currently holds the renewal role before you add or remove any CA replica.

Moving the renewal and CRL publisher role is a separate task with its own steps, and this section does not cover it. Plan it as a dependency: if your CA count changes, confirm where the renewal role sits, then decide whether it should move before or after the layout change. The sibling topic on the CA renewal server and CRL publisher roles covers the move and what breaks if that server disappears. Also verify the ipa-backup and ipa-restore procedure for your version on a lab copy of your topology, so you know how the CA data is restored if the renewal server is lost.

Risks of running the CA on a single server

A single CA host concentrates several failure modes in one machine: the loss of the only certificate authority, the stop of renewals and CRL publication, and restores that break replication. The cards below pair each risk with a placement or testing mitigation you can check in your own topology before you choose how many replicas carry the CA.

Loss of the only CA host

If the sole server running the Dogtag certificate authority fails and no other replica carries the CA role, certificate issuance for hosts and services stops. Existing certificates keep working until they expire, but new enrollments, renewals and service certificate requests cannot be fulfilled. Check that at least one other replica in each datacenter runs the CA, and confirm the recovery path with your own environment before go-live.

Renewal and CRL publication stopping

By default the first server handles certificate renewal and CRL publication. If that server is the only CA host or is taken offline without moving the role, renewals stop silently and revocation status is no longer published on schedule. Identify which server holds the renewal and CRL role, record it in your runbook, and plan how the role moves before any maintenance on that host.

Outdated backups breaking replication

Restoring an old backup into a topology where other replicas remain active can break replication, because the restored server no longer matches the changes the others have already applied. This risk grows with a single CA host, since a restore is often the only fast path back. Test restores in an isolated environment, and document which servers must be stopped or rebuilt before a restored CA host rejoins the topology.

Maintenance windows without a CA

Patching, upgrades and hardware work on the only CA server leave no CA available for the duration of the window. Any service that requests a certificate during that time will fail or queue. Plan at least one CA-capable replica so that one server can be taken down at a time, and confirm in a test environment how long your certificate requests can wait before they affect users.

CA-dependent services failing in a site outage

When the CA host sits in one site and that site is lost, services in the remaining sites may still need to request, renew or validate certificates. Without a CA replica elsewhere, those services depend on a link or host that is no longer reachable. Map which applications and clients depend on the CA in each site, and decide whether a CA replica in another site is needed to keep them running.

Setting up CA replicas in a planned order

This sequence adds certificate authority roles to FreeIPA replicas without disturbing the server that renews shared certificates and publishes CRLs. Each step ends with a check, so a failed replica is caught before clients depend on it.

Confirm the current renewal and CRL holder
Before changing anything, identify the server that renews shared certificates and publishes the certificate revocation list. Run the server role query from an existing administrator account and record the answer in your change record. By default this is the first server installed, but your environment may differ, so confirm it rather than assume it. Done when you have a written name for the renewal and CRL holder and a plan to keep that role in place during the change.
Decide the CA count for each datacenter
Work out how many replicas per datacenter will carry the CA role, using the vendor's deployment recommendations as your baseline. The recommendations advise at least one replica per datacenter running PKI when it is used, so plan that minimum for every site that issues or renews certificates. Record which servers will be CA replicas, which will not, and why, since this list drives every later step. Done when each datacenter has a named CA server list approved by the team that owns certificate policy.
Verify DNS and reverse resolution for the new replica
For each planned replica, confirm that its forward and reverse DNS records resolve correctly from the new host and from existing FreeIPA servers. Check that the host name matches the name you intend to install, and that the server can reach the existing servers on the ports FreeIPA uses. Fix any mismatch before installation, because a replica with bad name resolution is difficult to clean up later. Done when name lookups in both directions return the expected names from every node involved.
Install replicas with the CA role
Install each new replica with the CA role selected, following the detailed replica installation guidance in the sibling topic on installing a FreeIPA replica. Install one replica at a time so that a failure affects one server and not the whole change window. Do not move the renewal and CRL role during this step unless you have decided to do so in a separate, planned change. Done when the installer reports success and the new server appears in the server list with the CA role.
Check replication agreement counts
Count the replication agreements on each CA replica and compare the result with the recommendation of no more than four agreements per replica. If a server exceeds that limit, adjust the topology before you move on, since over-connected replicas add replication load without adding resilience. Review the agreements in both directions, because a link that exists on only one side can hide a broken path. Done when every replica is at or below four agreements and the topology still connects every datacenter.
Verify CA health and certificate replication
Check that each new CA replica reports healthy CA services and that certificate records created on one CA server appear on the others. Issue a short-lived test certificate from a new replica and confirm that it is visible from a different server and that the CA chain validates on a client. Treat any missing record or failed service check as a stop condition, and do not point clients or DNS locations at the server until it passes. Done when the test certificate is visible across servers and every CA service reports healthy.
Back up and test the restore
Take a full backup after the topology change and store it outside the FreeIPA servers. Then test a restore in an isolated environment, not on an active replica, because restoring an outdated backup into a live replica topology can break replication. Confirm that the restored copy holds the CA configuration and the expected server list. Done when you have a verified backup, a documented restore procedure and a note of who may run it.

Matching the CA count to deployment size and region

A single-site deployment keeps all FreeIPA servers in one physical or cloud location, so the main question is how many servers should carry the CA role for redundancy without creating unnecessary replication work. The CA role lives on a replica that runs the Dogtag certificate system, and every CA-enabled server must keep its certificate data in step with the others. A small set of CA servers covers a single server failure while keeping replication simple.

Redundancy target: Two CA-enabled servers cover the loss of one host, provided the remaining server is healthy and reachable by clients.
Renewal role: The first server holds the renewal and CRL publishing role by default, so confirm that role is not the only point of failure.
Replication load: Each added CA replica adds certificate replication traffic and another system to patch, back up and monitor.
Backup scope: A restore from an outdated backup into an active topology can break replication, so every CA server must be covered by the same backup routine.
Local failure: A single site does not protect against power, network or facility loss, so a single-site design accepts that risk.

Before fixing the count, pull the sizing and CA guidance for your FreeIPA version from Red Hat documentation and confirm it with your architect.

Keeping CA backups, renewals and access aligned

Once you decide which replicas carry the certificate authority, the backup plan, renewal monitoring and administrative access have to follow that layout. Start by deciding which backup type each CA replica gets. FreeIPA's ipa-backup supports full backups and online data-only backups, and the backup documentation warns that restoring an outdated backup into an active replica topology can break replication. That warning matters most for CA replicas, because a restore on one of them can leave certificate data out of step with the rest of the topology. Confirm with your own runbook which replicas take full backups, which take data-only backups, and what restore order you would follow after a loss. The FreeIPA backup and restore page is the reference for the exact options and their limits.

Backups are only useful if they are stored where a compromised or failed CA host cannot erase them. Keep copies off the CA hosts themselves, in a location with its own access controls, and record which replica produced each archive. Retention periods and who may read, copy or restore these archives should come from your own information security policy, not from FreeIPA defaults. Ask your security and compliance team to confirm those rules before the first backup schedule is set. Renewal health needs the same discipline. The first server holds the CA renewal and CRL publisher role by default, so monitoring should check that the renewal server is up, that certificate renewals complete, and that CRLs are still being published from the expected host. Alert on those signals, not only on host availability.

Access and change records complete the picture. Limit who can administer the CA to a named group of people, reviewed on a schedule you set, and keep that group separate from general server administrators where your policy requires it. Record every change to CA placement, including adding or removing a CA replica, moving the renewal and CRL role, and any backup restore, in a change log that names the approver and the date. Those records are the evidence an auditor will ask for when reviewing how certificate authority operations are controlled. Before you change the layout, confirm with your own team how each change is approved and where the record is kept.

Limits to confirm before choosing a CA count

The right number of CA replicas depends on limits that vary by FreeIPA version, hardware, network and key management. Confirm each item in your environment before you fix the layout, because several of them are hard to change after the CA is deployed on more servers.

Red Hat guidance for your version

Red Hat and the FreeIPA project publish topology guidance tied to specific releases, so the advice you read may not match the version you run. Ask your platform or Red Hat support contact which recommendations apply to your exact release and whether they cover CA replicas per site. Record the answer with the version number in your design document, since the guidance is the baseline your topology review will check against.

Replication agreement limit per replica

The community deployment recommendations advise no more than four replication agreements per replica. Every CA replica adds agreements on top of the directory agreements, so a CA server placed in a busy mesh can reach that ceiling quickly. Map the agreements each candidate server would hold before you pick it, and confirm with your team which links are required and which can be removed.

Hardware and network for extra CA replicas

Each CA replica runs Dogtag and holds a copy of the certificate data, so it needs CPU, memory, disk and a stable network path to its peers. Confirm with your infrastructure team that the candidate hosts meet the sizing guidance for your user and host counts, and that they are dedicated to FreeIPA. Ask whether the hosts can be patched and rebooted without a change freeze that would stall certificate work.

Whether HSM-backed CAs are in scope

If your CA keys live in a hardware security module, each CA replica may need its own HSM access, and key ceremonies multiply with the server count. Confirm with your security team and your HSM vendor whether the module can be shared or must be installed per server, and what the key backup procedure requires. Do not add CA replicas until that answer is known, because it can change the count you need.

Cross-site latency between CA replicas

CA replicas in different sites replicate certificate data over the wide area network, and slow or unstable links delay replication and certificate operations. Measure round-trip time and packet loss between the candidate sites with your network team, and check whether a site could be cut off for long periods. Those measurements decide whether a remote site should carry a CA replica or only a directory replica.

Upgrade path for the release in use

Each FreeIPA release changes server packages and the Dogtag components, and the upgrade order matters more as the number of CA servers grows. Ask your platform team which upgrade sequence your distribution supports, how many days a rolling upgrade across all replicas will take in your maintenance window, and whether a test replica can be upgraded first. Confirm the path before adding CA replicas that you would then need to upgrade in lockstep.

Questions buyers ask about FreeIPA CA servers

How many FreeIPA servers should run the CA?

Most teams should run the CA on at least two replicas in each datacenter that matters to them, and the FreeIPA deployment recommendations advise at least one replica per datacenter running PKI or DNS if those services are used. The count depends on how many sites you run, whether a site can be isolated during an outage, and how many replication agreements each replica can carry. The recommendations also suggest no more than four replication agreements per replica, so a larger topology needs deliberate planning rather than adding CA servers everywhere. Confirm the layout against your own site map before you decide.

What does it cost to add one CA replica?

The cost has four parts: the server (physical or virtual), the operating system and its support, the staff time to install and verify the replica, and the ongoing effort to patch and monitor it. Hardware and licensing costs recur or repeat per server, while installation and verification are one-time. Costs rise with the number of datacenters, the need for dedicated hardware, and any hardware security module used for CA keys. Ask any provider for a quote that lists each server, each site and each role separately, because a fixed-scope quote follows from that written scope.

How long does a CA layout change take to plan and verify?

The duration depends on the number of sites, the state of your DNS and reverse zones, and how much of the change touches the server that renews shared certificates and publishes CRLs. Planning covers role placement, replication agreements and DNS resolution checks. Verification covers replication health, certificate issuance, renewal and CRL publication from each affected server before clients are moved. Confirm the duration with the provider in writing, and ask which steps are included in the estimate.

What does the work need from our internal staff?

Your team needs to supply access to the FreeIPA servers, DNS and network records, datacenter and hardware details, and a named owner who can approve changes to CA roles. Engineers who know your Kerberos realm, DNS zones and change process will shorten reviews. Staff also need to be available for a maintenance window and for the test steps that confirm clients still authenticate. Ask the provider to list these inputs in the scope so you know your commitment before work starts.

Can our team change the CA layout without a partner?

Yes, if your team has FreeIPA operations experience and a tested backup and recovery plan. The risk is in the details: restoring an outdated backup into an active replica topology can break replication, and the first server holds certificate renewal and CRL publication by default. A team that has not done this before should rehearse the change in a non-production environment first. Consider a partner if you lack that experience or cannot take a replication outage.

What do the risks of a single CA server look like?

A single CA server means certificate issuance, renewal and CRL publication depend on one host. If that host fails and no other server holds the CA role, renewals can stop and revocation information can go stale. Recovery from backup is possible, but an outdated restore into a live topology can break replication, so the recovery plan needs rehearsal. Confirm which server currently holds renewal and CRL publication, and document the steps to move those roles before you need them.

How is a partner's fixed-scope quote built?

A DeployOpen quote follows from a written scope, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. The scope lists the sites, the number of CA and DNS replicas, the hardware or virtual machines involved, the testing to be done and the handover documents. Changes to the number of sites or roles change the quote. Ask for the written scope and check that it names your datacenters, replication design, testing and backup steps.

How DeployOpen works on this

DeployOpen plans, implements, hardens, documents and supports FreeIPA inside your own infrastructure, including the decision of which replicas carry the certificate authority. We start from your sites, user counts and recovery targets, then agree the layout in writing before any server is built.

How we scope

We map each site, its replicas and the roles each server would carry, including the CA, DNS and renewal server roles.
The written scope names which replicas run the CA, how many replicas per site are planned, and how certificate replication is verified.
Engagements are fixed-scope, so deliverables, timelines and acceptance checks are agreed in writing before work starts.

How we build

We install CA-capable replicas in a sequence that keeps replication agreements within the recommended limit per replica.
We test the failure of a single CA replica and confirm that certificate issuance and renewal continue from the remaining servers.
We confirm DNS and reverse resolution for each new server before any client is pointed at it.

How we hand over

You receive a topology document listing each server, its roles, its site and the replication agreements between them.
The runbook covers how to check CA health, where the renewal server and CRL publisher sit, and how to move those roles.
Backup and restore procedures are documented and tested against the final layout, including the warning about restoring outdated backups.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, covering changes to the CA server count over time.
Before you add, remove or rename a CA replica, we review the role transfers and the effect on certificate renewal.
We confirm the layout still matches your recovery targets after each FreeIPA release you plan to adopt.

How many FreeIPA servers should run the CA