Which FreeIPA server renews the CA certificates and publishes CRLs
In a multi-server FreeIPA deployment, one server quietly carries two jobs that every other server depends on: renewing the shared certificates issued by the integrated Dogtag certificate authority, and publishing the certificate revocation list (CRL). The first server installed in the topology holds the CA renewal server role by default, and the FreeIPA backup documentation warns about this placement directly: the first server handles certificate renewal and CRL publication by default, so it deserves explicit attention in any topology plan. Teams often discover the role only when a renewal fails or a replica is retired, so the question to answer early is which server holds it today and whether that choice still makes sense.
The renewal server is the Dogtag instance that performs scheduled renewal of the CA subsystem and shared certificates that all replicas use. The CRL publisher is the server that generates the revocation list and makes it available to clients and services that check whether a certificate has been revoked. These are distinct responsibilities, but FreeIPA assigns both by default to the first server. Run ipa config-show and check the CA renewal master field, then confirm with ipa-crlgen-manage status on each CA-enabled server which one publishes CRLs. Record both results in your topology documentation before any server is changed.
Check the role before planning a migration, a decommission or a major upgrade, and again after any change to the CA replicas. Moving the role is a supported step, but it must be done deliberately, and the new holder must be a CA-enabled replica that stays online. If the role-holding server disappears without a handover, renewals stop from that point and the CRL can go stale, which affects revocation checks across the estate. Confirm the procedure, the prerequisites and the verification steps against the current FreeIPA documentation for your release, and rehearse the handover in a non-production environment with your own backup and restore process.
Why the first server holds the renewal role by default
The first server in a FreeIPA deployment takes on the CA renewal and CRL publishing role when it is installed. The role is not a separate choice made later. It follows from the installation itself, so the server that built the deployment also becomes the one that renews the shared certificate authority certificates and generates the certificate revocation list that clients and services rely on. Nothing moves that role automatically when more replicas join, which means the default can persist for years unless someone deliberately reassigns it.
The FreeIPA backup documentation frames this default as an operational fact rather than a configuration option to tune. It states that the first server handles certificate renewal and CRL publication by default, and it warns that restoring an outdated backup into an active replica topology can break replication. Read together, those two points mean the renewal server is also the place where recovery mistakes do the most damage. Before you plan a restore, confirm which server currently holds the role by checking the CA server configuration in your own environment, and record that answer alongside your backup schedule.
The practical consequence of a single holder is that renewal and CRL publication depend on one host being available and correctly replicated. If that server is lost, decommissioned or left running with stale data, the duties do not fail over on their own, so the team has to notice and act. The safe response is to confirm a second server can take the role before you retire the first, and to plan the reassignment as its own change window. Ask your vendor or review the FreeIPA documentation for the exact procedure for your release, and do not assume a removal command will hand the role over cleanly.
Options for where the renewal and CRL roles live
This table compares three places to keep the CA renewal and CRL publisher role: the original first server, a longer-lived replica moved in during a migration, and CA-capable replicas spread across sites. Read each row against your own server count and site layout, and treat the per-datacenter recommendation as the baseline for any choice.
| Option | When it fits | Trade-off | What to confirm first |
|---|---|---|---|
| Keep the role on the original first server | Small deployments with one site, where the first server is stable, monitored and backed up | Default placement, so no change is needed, but the single host becomes a dependency for renewals and CRL publication | Which server currently holds the renewal and CRL roles, and whether a backup of it is tested |
| Move the role to a longer-lived replica during a migration | Migrations where the original first server is being retired or rebuilt and a newer replica will stay in service for years | Requires a deliberate role move before the old server is removed, and the role must be confirmed on the new host before decommissioning | Whether the target replica runs the CA role and has current replication to the rest of the topology |
| Spread CA-capable replicas across sites | Multi-datacenter deployments where a site may be lost or isolated | Each CA-capable replica adds replication and maintenance work, and the recommendation is at least one PKI-capable replica per datacenter | Which replicas carry the CA role at each site and how certificate data replicates between them |
| Single CA-capable replica without a standby | Rarely appropriate, since losing the only holder affects renewals and CRL publication | Lowest effort, but there is no second server to take over if the holder fails | Whether a documented recovery path exists for promoting another CA-capable server |
| Renewal role on a server outside the main site | Only where a specific network or regulatory reason exists and the placement is documented | Can complicate outages and access paths, so the server must be reachable and monitored like any other | Whether the chosen host has reliable connectivity to the other replicas for CA operations |
Checking and moving the renewal server role
This sequence confirms where the CA renewal and CRL publisher role sits, checks that every CA replica is healthy and backed up, and moves the role to a chosen replica with evidence that renewal and CRL publication still work afterward.
Identify the current renewal server
Before changing anything, confirm which server holds the CA renewal and CRL publisher role. Run
ipa config-showon any server and read the CA renewal master field, then check the same value from a second server. Both should return the same host name. Record the result in your change record, because the default is the first server installed, which may no longer be the server you expect after earlier changes.Confirm CA replicas and replication health
List the servers that run the certificate authority with
ipa server-role-find --role='CA server'and confirm that the replicas you plan to use as successors are CA servers. Then runipa-replica-manage listandipa-csreplica-manage liston the renewal server and check that every agreement is present and reports no errors. Do not proceed while any agreement is broken, since the role move depends on the topology sharing current data.Confirm current backups exist
Run a fresh full or data-only backup with
ipa-backupon the current renewal server and copy it off the host. Confirm the archive lists the expected components and can be read. The FreeIPA backup documentation warns that the first server handles certificate renewal and CRL publication by default, so keep this backup as your rollback point and label it with the date and the server name.Promote a suitable replica
Choose a CA replica in a well-connected site that has sufficient disk, time synchronization and DNS health, then make it the renewal target. Confirm with your own tests that the candidate resolves correctly in both directions and has no pending replication errors. The check is that
ipa config-showstill reports the old server until you complete the move, and that the candidate's CA service runs cleanly withipactl statusbefore you continue.Move the renewal and CRL role
Use the documented FreeIPA procedure for transferring the CA renewal master role to the chosen replica, typically with
ipa-csreplica-manageor the equivalent role command for your release. Make the change once, from a server that has current topology data, and avoid running it on two servers at the same time. The step is complete whenipa config-showon every server reports the new renewal master.Verify renewal and CRL publication
Confirm the new server can renew a test or non-production certificate and that it publishes the CRL at the expected location. Check the CA logs on the new server for errors, and confirm that the old server no longer attempts renewal. Keep the monitoring alerts for certificate expiry on, because a failed renewal may only surface days later.
Avoid restoring an outdated backup
If a rollback is needed, do not restore an older backup into a live replica topology. The FreeIPA backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Instead, rebuild affected replicas from the current topology, and use the backup only after the restore procedure has been reviewed and tested in an isolated environment.
What breaks if the renewal server disappears
The first FreeIPA server handles certificate renewal and CRL publication by default, so losing it affects more than one server. The cards below cover the services that stall, the restore assumptions that change, and the recovery work to plan before an outage happens.
Certificate renewal stalls
Shared certificates issued by the integrated Dogtag CA are renewed by the server holding the renewal role. If that server is gone, certificates nearing expiry are not renewed by the other replicas unless the role is moved. Check which server currently holds the role and track expiry dates for every shared service certificate, including the CA certificate itself.
CRL publication stops
The first server also publishes the certificate revocation list by default. When it disappears, new revocations are not reflected in a fresh CRL until another server takes over the publishing role. Confirm with your own runbook which server becomes the publisher and how that change is verified.
Clients may miss revocations
Relying systems that check CRLs can keep trusting a certificate that was revoked after the publisher went offline, because they only see the last list they downloaded. Ask which applications in your estate perform CRL checks and how long they cache revocation data.
Backup and restore assumptions change
The backup documentation notes that the first server handles renewal and CRL publication by default. A restore plan must name which server is restored, which role it resumes, and whether the other replicas still expect it to hold those roles. Document this before you rely on ipa-backup and ipa-restore.
Outdated restore can break replication
Restoring an outdated backup into an active replica topology can break replication, according to the backup documentation. If the CA role moves during recovery and an old backup is brought back online, the replicas may disagree about state. Restore into an isolated environment first and confirm replication health before reconnecting.
Recovery work after unplanned loss
An unplanned loss forces a role transfer, a replacement server and a check of certificate state while the outage is already underway. Plan the replacement path in advance, including which replica will take over renewal and publishing, who is authorized to make the change, and how the decision is recorded for auditors.
Limits to confirm for your FreeIPA version and environment
Which procedure applies to my installed FreeIPA version?
The exact steps for moving the CA renewal and CRL publisher role depend on the FreeIPA release and the CA installation type on your servers, so the procedure must be taken from the documentation for your installed version. The supplied backup documentation confirms that the first server holds these roles by default and warns about restoring outdated backups into an active topology, but it does not give a step-by-step role transfer for every release. Ask your vendor or implementation partner to confirm the procedure against your exact version and CA configuration, and test it on a copy of the topology before production use.
Can the CA renewal role be moved in my FreeIPA release?
Confirm this for your release before planning a migration, because the supported method for reassigning the renewal and CRL role is not something this page can verify for every version. Check the release notes and upgrade documentation for your installed version, and confirm with the vendor whether the role can be reassigned in place or only through a replacement server. Record the answer in your change plan so the migration sequence reflects what your release actually supports.
How does an HSM-backed CA change the renewal role?
An HSM-backed CA adds key custody requirements that can change how the renewal role is moved, backed up and recovered, so treat it as a separate planning item. Confirm with your HSM vendor and the FreeIPA documentation for your version how CA signing keys are referenced on each server, whether keys can be accessed from a new server, and what happens to renewal if the HSM is unavailable. Do not assume that a standard role move covers HSM-held keys until both sides have confirmed it in writing.
How are externally issued certificates handled during a role move?
Certificates issued by an external CA, or certificates a team imported into FreeIPA, need their own inventory and renewal path, because the renewal server does not remove the need to track them. List every certificate that clients, services or applications depend on, record its issuer and expiry, and confirm how each one is renewed after the role moves. Ask your security team and the FreeIPA version documentation to confirm whether any externally signed chain or subordinate CA relationship changes when the renewal server changes.
What should I check in the CRL publishing path before cutover?
Confirm where clients and relying services fetch the certificate revocation list, and whether that location changes when the publisher role moves. Verify the URL that your services use, the network path to the new publisher, and the publishing schedule in your version. Test revocation checking from representative clients before and after the change, because a stale or unreachable CRL can cause certificate validation failures that appear only in some applications.
What breaks if the renewal server is lost without a plan?
If the server holding the renewal and CRL role disappears without a planned handover, certificate renewal and CRL publication can stop, and certificates may expire before anyone notices. The exact recovery path depends on whether other replicas hold the CA role and on your version, so confirm with the vendor documentation how the role is recovered and whether an outdated backup could disrupt replication. Keep a tested runbook and monitor certificate expiry dates so the gap is visible early.
Who should own the role move and what does it cost?
Decide whether your own platform team or an implementation partner will carry out the move, because that choice drives most of the cost. Your team pays in staff time and test environments, while a partner's fee follows from a written scope that covers the procedure, the HSM and external certificate work, verification and rollback. No figure applies across environments, so ask any provider for a quote based on your topology, CA configuration and version, and ask which items are one-time work and which recur as ongoing support.
How DeployOpen scopes CA role changes
DeployOpen plans and implements FreeIPA inside infrastructure you control, including your cloud accounts, data centers or air-gapped networks, so any move of the CA renewal and CRL publisher role happens on your servers under your change process. Before any work starts, we document where the role sits today: which server holds it, which replicas carry the Dogtag CA, whether any other server could take over, and what the most recent backup contains. That inventory is the basis for the written scope, which states the target server, the migration steps, the validation checks and the rollback point.
A fixed scope fits this work because the steps are known in advance, but the environment rarely is. We confirm the current topology with you, agree the change window and the owners on each side, and record the deliverables in writing before any change is made. If the work turns up something outside the agreed scope, such as a replica that cannot reach the new CA server, we stop and agree a change to the scope rather than absorbing it silently. Follow-up checks after the role move, such as reviewing CRL publication or certificate renewal reports, can be covered by a retainer if you want continued support.
DeployOpen prepares evidence for your compliance assessments, including configuration records, role placement diagrams, change logs and test results. We do not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so ask your assessor early which records they expect and confirm with them how the CA role change should be documented for your control framework.
