Renewing an externally signed FreeIPA CA certificate

Why an externally signed FreeIPA CA certificate needs manual renewal

If your FreeIPA CA chains to a corporate root or Microsoft AD Certificate Services, FreeIPA cannot renew the CA certificate on its own. The external CA signed the FreeIPA CA certificate, so only that CA can issue its successor, and an operator must generate a request, have the external CA sign it, and install the result. You need this procedure when the CA certificate approaches expiry, and you should plan it well before that date. The external CA signs the root of the FreeIPA certificate chain, which is the ipa CA certificate that FreeIPA uses to issue service, host and user certificates. Those end-entity certificates depend on it, so an expired CA certificate stops the whole PKI from validating, not just one service.

Renewal is not optional, and it is anchored to the first server in your topology. The first server you installed acts as the renewal master by default, the same role the FreeIPA backup documentation describes when it says that server handles certificate renewal and CRL publication. Renewal work therefore starts there. Check the expiry date of the CA certificate with the external CA's records and with ipa-cacert-manage on that server, and confirm which server holds the renewal master role before you schedule the change. Also confirm whether your environment used a two-step --external-ca install, because that history shapes the signing request you will produce. The sibling topics on installing with an external CA and on recovering from expired certificates cover those paths in detail.

Because this work touches every machine that trusts the FreeIPA CA, you should treat it as a change with a named owner, a window, and a rollback plan. Ask your external CA team how they will sign a request for a CA certificate, which certificate profile they will use, and how long their process takes. Then confirm with the FreeIPA release notes and documentation for your version that the commands and renewal behavior match your installation. Any server that misses the new certificate will keep trusting the old one, so the inventory of enrolled clients and their trust stores is part of the plan from day one.

Renew the FreeIPA CA certificate with a CSR

This sequence takes an externally signed FreeIPA CA from a planned renewal request to a verified state, with a backup and a signed chain in place before any change reaches the rest of the topology. Each step closes with a check so the operator knows whether to continue.

Confirm the renewal master and current expiry
Run the checks on the first server, which handles certificate renewal and CRL publication by default. Confirm that it is the renewal master, then record the expiry date of the current CA certificate and the expiry of the other certificates in the deployment. Check the server's view of the CA with ipa-cacert-manage status options and getcert list for the tracked certificates, and confirm that the external CA is still available to sign. Done when you have a written note of the renewal master hostname, the CA expiry, and the signing contact or portal for the external CA.
Back up the deployment before any change
Take a full backup with ipa-backup on the renewal master and copy it off the server. Use the full backup type rather than an online data-only backup for this change, and store the copy somewhere the renewal master cannot overwrite. Confirm that the backup files exist, have a non-zero size, and can be listed or verified with the tool's options available in your installed version. Do not proceed until you can name the backup file and its location, since restoring an outdated backup into an active replica topology can break replication.
Generate the CSR with ipa-cacert-manage renew
On the renewal master, run ipa-cacert-manage renew with the option that writes a certificate signing request for an external CA rather than renewing with the internal Dogtag CA. Confirm the exact option name and output path against the installed FreeIPA version, since flags differ between releases. Save the CSR file and check that it contains the expected subject and key details for the IPA CA. Done when the CSR file is present, readable, and you have confirmed that the request is for the CA signing certificate and not a service certificate.
Have the external CA sign the request
Submit the CSR to the external CA owner, such as your corporate root or a Microsoft AD Certificate Services team, and ask for a CA certificate with the CA basic constraints and key usages that FreeIPA requires. Request the full chain back, not only the leaf certificate. Confirm the validity period and subject with the signer before you accept the result. Done when you hold the signed certificate and the issuing chain as separate files, and the subject matches the CSR you submitted.
Install the returned certificate and chain
Install the signed CA certificate with ipa-cacert-manage using the option for an externally signed renewal, pointing it at the returned certificate and the chain file. Confirm the exact flags for your version before running the command. Afterwards, check that the new certificate is the one the CA now reports, and that the chain verifies to the external root with openssl verify against the trust store you intend to use. Done when the installed certificate shows the new expiry and the chain validates.
Run ipa-certupdate on every server and client
Run ipa-certupdate on each IPA server, then on each enrolled client and any system that trusts the IPA CA through its own store. This refreshes the local copy of the CA certificate so that services and clients accept certificates signed under the renewed CA. Start with the renewal master, then the replicas, then clients, checking each host's output for errors before moving on. Done when every host reports success and a test certificate check against the new chain passes on a sample of hosts.
Verify CA status and tracked certificates
On the renewal master, confirm the CA status with ipa-cacert-manage and ipa cert-find or the equivalent check for your version, and confirm that services, replicas and certmonger-tracked certificates still renew. Check that replication is healthy after the change and record the new CA expiry in your renewal calendar. Done when the CA reports as running with the new certificate, replication shows no errors, and the verification results and backup reference are filed with the change record.

Renewal options and when each fits

This table compares the three paths an operator faces when an external CA signed the FreeIPA CA: renewing with a CSR to the same external CA, moving to a new external hierarchy, and falling back to a self-signed CA. Read each row for its trust impact, its downtime exposure and the parameters to settle with the external CA team before the renewal window opens.

Option	Trust impact	Downtime exposure	When it fits
Renew with a CSR to the same external CA	Keeps the existing root or intermediate trusted by enrolled clients, so chain changes stay limited to the new leaf or subordinate certificate	Low to moderate, mainly during the rollout of the new certificate and ipa-certupdate on every host	The organization still operates the issuing CA and wants continuity with existing clients and trust stores
Renew into a new external CA hierarchy	Every client, service and application that trusts the old root must also receive the new root and chain	Higher, because trust distribution must finish across all hosts before services rely on the new chain	The old CA is being retired or re-keyed, and the organization can run a planned trust migration
Fall back to a self-signed FreeIPA CA	Clients trust only the new internal root, so every service and external consumer that relied on the corporate chain needs updating	High, since certificates from the external chain stop validating until each consumer is changed	Used as a last resort when the external CA cannot sign in time, and only with a documented plan to return to external trust
Renew with a new key pair from the same CA	Depends on the CA policy for re-keying, which may or may not preserve the existing subject and trust anchor	Moderate, because CSR parameters and profile mapping must be checked before submission	The current key is weak, scheduled for retirement, or stored outside policy
Confirm with the external CA team before submitting	Ask which certificate profile, key size, validity period, path length and extensions apply to the subordinate CA	Ask how long signing takes and whether an out-of-hours signing window exists	Use this check for every option above, since the answers set the CSR content and the rollout order

Running ipa-certupdate on every server and client

Every IPA server and every enrolled client keeps its own copy of the trusted CA chain, so a renewed FreeIPA CA certificate does nothing for a host until that host refreshes its store. Run ipa-certupdate on each IPA server and each client after the new certificate is installed. On an IPA server, the command rebuilds the local trust store and the files that services read, including the LDAP and HTTP certificate configuration, from the directory. On a client, it fetches the CA certificates that FreeIPA publishes and updates the system trust store, so that tools such as the SSSD-backed login path and browsers accept certificates signed under the renewed chain. Confirm the exact files and behavior for your release against the FreeIPA documentation before you write runbooks around them.

The order matters. Update the replicas and the renewal master first, then the remaining servers, then clients. A replica that still trusts only the old chain can fail TLS handshakes with peers that already present certificates under the new one, and replication or certificate-based API calls between servers can fail in ways that look like network faults. Stale clients fail more quietly: SSSD may refuse to connect to an LDAP or Kerberos service over TLS, ipa commands run from the host can report certificate verification errors, and enrolled users may be unable to log in over services that rely on the FreeIPA chain. Do not rely on a host's uptime or its last reboot as evidence that it is current. Keep a dated record of when each host was refreshed.

To find hosts that need the update, start from the IPA server list (ipa server-find) and the host list (ipa host-find), then compare against what is actually enrolled on the network, because hosts can exist in the directory without being reachable and machines can be enrolled outside your normal process. Check whether each host has the new CA in its trust store before you consider it done. For machines enrolled in bulk or through automation, record the method in your enrollment runbook so the refresh is repeated in the same way. The sibling topic on FreeIPA client enrollment and SSSD covers enrollment methods, re-enrollment and the host states you will meet, and it is the right next read before you schedule the refresh across a large fleet.

Security risks in CA renewal and how to control them

Renewing an externally signed CA touches the most sensitive material in a FreeIPA deployment: the CA signing key, the chain that clients trust and the servers that publish and renew certificates. The cards below cover where those risks sit and the checks that keep the renewal from becoming a trust or availability incident.

CA private key and CSR origin

The CA signing key stays on the FreeIPA server, and the renewal CSR is generated there from that existing key. Confirm that no one copies the key off the server to produce or sign the request elsewhere. Check that the CSR's subject and key parameters match what your external CA is expected to sign, and that the request is transferred through a channel your PKI team controls.

Handling of the signed chain

The external CA returns a certificate and usually a chain, and both must be installed exactly as signed. A wrong or partial chain makes the renewed CA look valid on one host and untrusted on another. Before installing, verify the chain against the root your clients already trust, and record the certificate fingerprints so later checks can confirm what was deployed.

Renewal master as a single point of change

By default the first server handles certificate renewal and CRL publication, so the renewal runs there and its results must reach every replica. Treat that server as the single point of change for the CA. Plan the maintenance window, confirm which server holds the renewal role before you start, and keep a backup taken immediately before the change.

Restoring an outdated backup into an active topology

FreeIPA's backup documentation warns that restoring an outdated backup into an active replica topology can break replication. If a renewal goes wrong and the team restores an older backup while other replicas are still running, the topology can diverge. Stop and check replication state before any restore, and confirm with your team which backup is the correct recovery point.

Access control on who runs renewal

Renewal changes the trust anchor for every enrolled machine, so only a small set of administrators should be able to run it. Limit administrative access to the renewal master, record who requested the CSR and who installed the certificate, and review those accounts before and after the change. Written approval from the PKI owner should precede the first command.

What teams ask before renewing an external FreeIPA CA

How long does renewing an externally signed FreeIPA CA take?

Duration depends less on the renewal command than on how long the external CA takes to sign the request and how many hosts must be updated afterward. The work has three phases: generating the renewal request and getting it signed, installing the new certificate on the CA servers, and running ipa-certupdate on every enrolled host and replica. Each phase has an external dependency that you do not control, so schedule the signing step first and confirm the external CA's turnaround time in writing before you set a cutover date. Ask your partner for a written timeline tied to the scope, and ask the external CA team for their approval lead time.

What does the renewal cost, and what are we paying for?

The cost has four components: the internal engineering time to plan and execute the change, any partner fee for scoped implementation support, the external CA's signing charge, and the operational effort of checking every host afterward. Only the external CA's fee and your staff time are typically certain before work starts, so ask for a quote that lists each item separately. Renewal is generally a one-time event for each certificate, but the next renewal recurs on the certificate's validity period, so ask whether the quote includes a runbook your team can reuse. DeployOpen does not publish prices. A quote follows from a written scope.

What do we need from our internal team and the external CA team?

Your internal team owns the FreeIPA servers, the change window, the list of enrolled hosts and the configuration management that will run ipa-certupdate. The external CA team owns the signing policy, the approval workflow and the delivery format of the signed certificate and chain. Agree on the CSR parameters, certificate profile, validity and chain format before anyone generates a request. Confirm who receives the signed files, where they are stored and who verifies the chain. Missing any of these owners usually surfaces as a delay after the CSR has already been sent.

Can our own team renew the FreeIPA CA certificate without a partner?

Yes, if your team has administrators who understand FreeIPA certificate handling, access to the first server and a tested rollback plan. The renewal flow uses ipa-cacert-manage renew with a CSR, followed by installing the returned certificate and running ipa-certupdate across the environment. The risks are concentrated in ordering mistakes, incomplete host coverage and the lack of a rehearsal. A partner is most useful when the team has not done this before, when the deployment spans several sites, or when the change must fit a regulated change process. Ask any partner to show how scope, deliverables and handover are documented.

How should we test the renewal before cutover?

Test in a non-production FreeIPA deployment that matches your production topology, with the same external CA profile and a representative set of clients. Generate a test CSR, obtain a test signature, install it, run ipa-certupdate on sample clients and replicas, then verify that TLS to the web UI and LDAP, Kerberos logins and certificate-based services still work. Take a full backup with ipa-backup before the production change, because the backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Record each check so the production change repeats the same steps.

What happens if a host misses ipa-certupdate?

A host that did not run ipa-certupdate keeps the old CA trust information. Clients may then fail to validate certificates issued after the change, including certificates for the web UI, LDAP connections and services that trust the FreeIPA CA. The symptoms often appear as intermittent errors on specific machines, which makes them hard to diagnose from the server side. Build a host inventory before the change, run ipa-certupdate through configuration management, and report the result per host. Re-run the command on any host that fails, and recheck it after its next configuration cycle so that a rebuilt machine does not inherit an outdated trust store.

Does DeployOpen issue the renewed certificate?

No. DeployOpen does not issue audit reports, attestations or certificates. The external CA signs the renewal request, and the signed certificate and chain come from that CA. DeployOpen can plan the change, prepare the FreeIPA side, run the renewal steps in your environment as agreed in the written scope, document the result and help you confirm that the trust chain is delivered to every host. Confirm with the external CA which certificate profile, validity and chain format it will use, because those decisions are outside the FreeIPA procedure.

Limits to confirm in your environment

Renewing an externally signed CA touches your installed FreeIPA version, your external CA's policy and every enrolled client. The cards below list the points to confirm with the FreeIPA documentation for your version, your CA team and your own inventory before a CSR leaves the building.

Exact command options for your version

The ipa-cacert-manage renew options, their defaults and the output format can differ between FreeIPA 4.x releases. Run ipa-cacert-manage renew --help on the installed server and compare it with the release notes for that version. Record the exact syntax in your change plan so the operator does not rely on examples written for a different release.

CSR type accepted by your CA

Ask the external CA team which CSR format they will sign, and whether they expect a Microsoft certificate services template or a generic PKCS #10 request. A CSR your CA rejects or re-encodes will stall the renewal after the private key is already in use. Confirm the signing template before you generate the request.

Validity and extension requirements

Your CA policy sets the validity period, key size, basic constraints, key usage and path length for an intermediate CA certificate. Those values can differ from the certificate you are replacing. Ask for the policy in writing and check the returned certificate against it before you install it, because FreeIPA will not correct a non-compliant chain for you.

Chain delivery to every server

A renewed CA certificate must reach every IPA server, and the root and any intermediate certificates must be in the trust path. Confirm who owns the full chain file, how it is distributed to replicas, and whether your CA publishes a new root or only a new intermediate. Missing intermediates are a common cause of failed trust checks after a renewal.

Clients that are not yet updated

Clients run ipa-certupdate to fetch the CA certificates they trust. Until that runs, machines may keep validating against the old chain and fail for certificates issued under the new one. Inventory enrolled hosts, identify those that are offline, unmanaged or on older images, and decide how long the old and new chains must overlap.

Renewal master and replica roles

The first server in your topology handles certificate renewal and CRL publication by default, so confirm which server holds that role before you start. Check that replicas receive the new CA material through replication and that no replica is left with an outdated backup. Restoring an old backup into an active topology can break replication, so take a fresh backup first.

How DeployOpen scopes and delivers CA renewal work

DeployOpen plans and carries out external CA renewal for FreeIPA inside your own infrastructure, from the CSR through to every enrolled machine trusting the new chain. Each step is agreed in writing before work starts, so your CA owners, IPA administrators and change board know what will be touched and when.

How we scope

Inventory the IPA topology, the renewal master and the current CA certificate expiry date before quoting.
Confirm which external CA issues the renewal and what certificate profile and chain format it will return.
Agree in writing which replicas, client groups and services are in scope, and who signs off each change.

How we build

Prepare a CSR with ipa-cacert-manage renew --external-cert-file on the renewal master, using your approved key parameters.
Install the externally signed certificate and chain on the renewal master, then verify the chain end to end.
Run ipa-certupdate on every server and enrolled client, and check trust on representative hosts before wider rollout.

How we hand over

Document the exact commands, file locations, dates and rollback steps used during the renewal.
Record the verification results, including trust checks on replicas and sample clients, as evidence for your assessors.
Walk your operations team through the renewal calendar so the next external CA renewal is planned before expiry.

How we support

Engagements are fixed-scope, with deliverables and timelines agreed before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer if you want DeployOpen to keep the next renewal on track.
Ask any partner for the written scope, the list of systems touched and the acceptance criteria before signing.