FreeIPA web and LDAP third-party certificates

How to replace FreeIPA web and LDAP certificates with third-party certificates

Replacing the FreeIPA Web UI and LDAP certificates has two parts: a server certificate for each FreeIPA server that the corporate or public CA signs, and trust in that issuing CA on every machine that connects. Teams usually need this when a security policy requires browser and LDAP clients to validate certificates from a CA the organization already manages, when an auditor asks for certificate issuance to be traced to a single approved authority, or when external users cannot be expected to trust an internal Dogtag root. FreeIPA combines 389 Directory Server, MIT Kerberos, the Dogtag certificate system and SSSD on clients. Dogtag is the component that issues certificates by default, and that default does not change. Replacing the web and LDAP server certificates does not remove the internal CA, its renewal of internal service certificates, or its role in certificate profiles and revocation.

The server certificate step is where most of the work sits. You generate a request for each server, have the external CA sign it, and install the certificate and chain with the FreeIPA tooling, including the ipa-server-certinstall utility. Trust comes first in practice: ipa-cacert-manage install adds the issuing CA to the FreeIPA trust store, and the trust must then reach every enrolled machine through ipa-certupdate and any non-IPA systems that rely on their own bundles. Confirm the exact command options, the accepted certificate and chain formats, and the order of operations against the FreeIPA documentation for your release before you change production. Plan a maintenance window, because a mistake in the server certificate or the chain can block web logins and LDAP binds at the same time.

Before you start, decide who owns renewal of the externally issued certificates, since FreeIPA will not track them the way it tracks certificates it issues itself. Record each server's certificate subject, subject alternative names, expiry date and the external CA's revocation endpoints so that a lapse is visible before it breaks sign-in. Ask your CA team which certificate profile and key type they will issue for LDAP and HTTP use, and test the new chain from a Linux client, a browser and an LDAP client with certificate validation turned on. Keep a copy of the pre-change configuration and a current backup, because the rollback path depends on both.

Which certificate source fits each FreeIPA service

This table compares three sources for the FreeIPA Web UI and LDAP certificate: the integrated Dogtag CA, a corporate issuing CA added with ipa-cacert-manage install, and a server certificate from a public CA installed with ipa-server-certinstall. Read each row for what changes on the servers and enrolled machines, then match the option to your trust model and renewal capacity.

Option	What it changes	Who must act on enrolled machines	When it fits
Keep the integrated Dogtag CA	The Web UI and LDAP certificates stay issued by the ipa CA. No server certificate replacement is needed and renewal stays with FreeIPA.	Nothing beyond normal enrollment, since clients already trust the ipa CA chain.	Internal services only, where clients are enrolled and no outside browser needs to trust the certificate.
Corporate CA through an issuing or subordinate CA	Add the issuing CA to FreeIPA's trust store with ipa-cacert-manage install, then issue the server certificate from that CA and install it with ipa-server-certinstall.	Administrators must run the CA update on every enrolled machine so the chain is trusted, and confirm the chain is complete before cutover.	Organizations with an internal PKI that already governs trust, renewal and revocation for corporate services.
Public CA server certificate	Replace the Web UI and LDAP certificate with one issued by a public CA using ipa-server-certinstall. The public root is usually already trusted by browsers and common operating systems.	Clients may still need the CA update step if the issuing chain is not in their default trust store. Confirm this per distribution.	External-facing or browser-accessed endpoints where clients outside the enterprise must trust the certificate without manual import.
Renewal responsibility	With a third-party certificate, renewal of the server certificate is handled outside FreeIPA's automated renewal flow for that certificate.	Renewal calendars and CSR steps must be tracked by the operations team, with a re-run of the install step at each renewal.	Teams that can own a renewal process with alerts well ahead of expiry.
Replica coverage	Each replica in the topology needs the same trust and server certificate changes, because each server presents its own Web UI and LDAP endpoints.	Operators must repeat the install and trust steps on every replica, not only the first server.	Any deployment with more than one server, which is the normal layout described in the deployment recommendations.
Dogtag CA still in use	Dogtag remains the CA for FreeIPA's own services and issued user or host certificates even after the Web UI and LDAP certificate changes.	Enrolled clients keep trusting the ipa CA, so existing enrollments are not invalidated by the change.	When the goal is only to change the name on the Web UI and LDAP certificate, not to remove Dogtag.
Verification before cutover	Confirm the served certificate chain, hostnames and validity on every server, and test LDAP and Web UI logins from a representative enrolled client.	Client owners should confirm login and browser trust on their own machines after the change.	Use this check whichever source you choose, since failures often appear as trust errors on clients rather than server errors.

Why the server certificate alone does not finish the job

A new web or LDAP server certificate helps clients only if they already trust the authority that signed it. In a FreeIPA deployment that authority is usually the corporate or public CA you chose, so the first job after issuing the certificate is to make that CA part of FreeIPA's own trust configuration with ipa-cacert-manage install, followed by ipa-certupdate on each server so the change is picked up. Until that step is complete, the server may present a valid certificate that FreeIPA itself does not recognize as anchored to a trusted root. Confirm the exact command options and any required follow-up steps for your release before you change a production server.

Trust is not held only by the FreeIPA servers. Every enrolled host keeps its own copy of the trusted CA list, and any other system that connects to the LDAP port or the Web UI, including scripts, Ansible controllers, monitoring agents and applications that bind to LDAP, must trust the same chain. Plan the rollout as an inventory exercise: list every enrolled host and every non-enrolled client, record how each one builds its trust store, and confirm that each has received the new CA before you switch the certificate on the server. A single machine that still trusts only the old chain can fail login, sudo or API calls with a certificate verification error, and that failure may appear only on that host, which makes it hard to spot from the server logs alone.

The Dogtag CA does not disappear when you replace the web and LDAP certificates. Unless your design changes, it continues to run internally and keeps issuing the certificates that FreeIPA uses for its own services and for certificates you request through the normal tooling. Treat that boundary as something to confirm rather than assume: check which certificates your release's Dogtag instance still issues, whether renewal and CRL publication remain on the first server, and which services keep relying on the internal chain. Document the result, because it determines which trust changes are needed and which certificates your renewal calendar must still track.

Setup sequence for swapping in a third-party web and LDAP certificate

This sequence replaces the FreeIPA Web UI and LDAP certificates with ones issued by a public or corporate CA, while keeping the issuing chain trusted on every enrolled machine. Each step ends with a check so the team can confirm the change before moving on.

Inventory names, clients and the renewal master
List every hostname and DNS alias that users or clients use to reach the Web UI and LDAP on each IPA server, including load balancer names. List the client groups that depend on those names, such as SSSD hosts, Kerberos-only services, applications with bundled CA stores and containers. Identify which server is the renewal master, since by default the first server handles certificate renewal and CRL publication, and record the decision in writing before any change. Done when the team has a signed-off name list, a client inventory and a named renewal master.
Obtain and validate the issuing CA chain
Request the full chain from the public or corporate CA: the issuing intermediate, any parent certificates and the root, in PEM form. Confirm each certificate's validity dates, that the server certificate will carry the right key usage for TLS server authentication, and that the subject alternative names cover every name from the inventory. Use a tool such as openssl to read each certificate and verify the chain against the root you intend to trust. Done when the chain verifies offline and the team can show the validity and key usage of each certificate.
Back up the server configuration before changes
Take a full backup of each IPA server with ipa-backup before touching certificates, and store it off the server. Confirm the backup files exist and record the FreeIPA version on each server so a restore targets the same release. Keep the backup from the renewal master in particular, because the backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Done when each backup is copied to a separate location and its file list has been checked.
Add the issuing CA to FreeIPA trust
On the renewal master, add the issuing CA and its chain to the IPA trust store with ipa-cacert-manage install, using the PEM files from the earlier step. Then run ipa-certupdate so the IPA CA store is refreshed. Repeat only what the replica topology requires, and confirm that each server reports the new CA. Done when ipa-cacert-manage lists the added CA on every server and ipa-certupdate completes without errors.
Request and install the server certificate
Generate a key and CSR for the Web UI and LDAP names, or let the CA issue from the CSR prepared in the inventory step, then install the signed certificate and chain with ipa-server-certinstall on the renewal master. Run the tool with the key, certificate and chain files, and use the web and directory options so both services receive the new certificate. Done when ipa-server-certinstall reports success and the certificate file path is recorded in the server configuration.
Restart services and verify the served chain
Restart or reload the web server and directory services as the install output directs, then check the result from a machine outside the IPA servers. Use a TLS client such as openssl s_client against the Web UI port and the LDAPS port to confirm the presented certificate, its names and the full chain. Confirm that the chain validates against the root in the client trust store. Done when both endpoints present the expected certificate and chain verify with no errors.
Test Kerberos and LDAP over TLS from clients
From a test enrolled client, obtain a Kerberos ticket with kinit for a test account, then run an ldapsearch against the LDAP name using TLS and the new trust store. Confirm that SSSD resolves users and that a login succeeds. Repeat the test against each replica so every server presents the new certificate. Done when Kerberos login and LDAP-over-TLS queries succeed on each server and client group identified in the inventory.
Update trust on every enrolled machine
Distribute the issuing CA and chain to every enrolled machine and any application stores that do not read the system trust, then refresh system trust with the distribution's standard command and confirm that clients trust the new chain. Run ipa-certupdate on enrolled hosts where IPA manages the CA store, and retest a client in each group. Track completion against the inventory so no machine is missed. Done when every client in the inventory validates the new chain and the team records the final check results.

Where third-party certificate swaps usually break

Most failed certificate swaps are not caused by the new certificate itself. They come from names, chains, machines and servers that were missed during the change. Each card below names one failure, the symptom it produces and the check that catches it before users do.

Name mismatch on the certificate

The certificate's subject name or subject alternative name (SAN) does not match the host name clients use to reach the Web UI or LDAP port. Browsers and SSSD reject the connection, and the error often looks like a generic trust failure. Before the swap, list every name clients use, including short names and load balancer aliases, and confirm each one appears in the SAN. Then test with the same name the client uses, not the server's own hostname.

Incomplete certificate chain

The server presents the leaf certificate without the intermediate CA certificate, so clients that do not already trust the intermediate fail verification. Some clients succeed because they cache the intermediate, which hides the problem until a new client or a cleared cache hits it. Check the chain the server sends, not only the file you installed, and verify it from a machine with no prior connection to the service.

Machines not updated after the CA change

Enrolled hosts keep the old CA trust in their local store, so tools on those machines reject certificates issued by the new authority. The symptom usually appears on one distribution or one group of hosts, which makes it look like a local fault. Run ipa-certupdate on each enrolled machine after the change, then confirm the new issuing CA appears in the local trust store before you retire the old one.

LDAP clients pinning the old certificate

Applications and services that pin the previous LDAP certificate or a copy of the old CA fail once the server certificate changes. The failure shows as TLS handshake errors on LDAP binds, and it can affect services that are not FreeIPA clients at all. Inventory every system that binds to LDAP, including appliances and applications with their own trust stores, and test each bind against the new certificate before the cutover.

Replicas left on the old certificate

The server you changed serves the new certificate, but replicas still present the old one, so clients that land on a replica see a different identity. Load balancing or DNS round-robin then produces intermittent failures that are hard to reproduce. Apply the change to every replica that serves the Web UI or LDAP, then query each server directly and compare the certificate fingerprints before you close the change.

Renewal tracking never configured

The new certificate has an expiry date, but nothing tracks it or renews it, so the same outage repeats at expiry. The first sign is often an alert from an external monitor or a user report, months after the change. Before go-live, record the expiry date, set up a renewal process with a named owner, and add an expiry check to monitoring that alerts with enough lead time to act.

How the approach differs by environment

When the issuing authority is Microsoft Active Directory Certificate Services, the web and LDAP certificate usually chains to an enterprise root or subordinate CA that Windows already trusts through Group Policy. The FreeIPA host must trust that chain, and the certificate template you request must allow server authentication with the subject and key settings your FreeIPA services need. The Windows PKI team typically owns the templates and the CA, so the request goes through them rather than through FreeIPA administrators alone.

Template settings: Confirm the template allows server authentication, the key length and the subject alternative names for every hostname that clients use.
Chain delivery: Ask for the full chain, including any intermediate CA, in the format your FreeIPA host can import.
Revocation endpoints: Confirm the CRL or OCSP locations in the certificate are reachable from the FreeIPA server and from clients.
Validity period: Ask how long the certificate lasts and whether the template auto-renews, since FreeIPA will not renew a certificate it did not issue.
Trust distribution: Ask whether the root is already pushed to Linux clients, or whether you must distribute it yourself.

Before you start, confirm the template name, the chain and the renewal owner with the Windows PKI team. For the full chaining procedure, see the sibling topic on installing with an externally signed CA.

Security and operational controls to set before the change

Replacing the Web UI and LDAP certificates touches the trust path for every login and every enrolled machine. The controls below decide whether the change can be reversed, traced and maintained after the people who made it have moved on.

Protect the server certificate private key

The private key for the new Web UI and LDAP certificate should be generated on the IPA server or in a controlled workflow, stored with restrictive file ownership, and never copied into tickets, chat or shared repositories. Confirm who can read the key file, how the CSR is produced, and whether the key is included in your backup scope. A leaked key lets anyone impersonate the server to clients that trust the chain.

Limit who runs the change

Name the individuals allowed to run ipa-cacert-manage install, ipa-server-certinstall and the trust update on every machine. Keep the list short, record it in the change request, and separate the person who requests the certificate from the person who installs it where your team is large enough. Confirm that these administrators hold FreeIPA admin rights only for the window, not permanently.

Keep an audit trail of the change

Record the CSR details, the issuing CA, the certificate serial and validity dates, the command output, and the time each server and client was updated. Store these records outside the FreeIPA servers so they survive a failed change. Confirm that your audit logs capture the administrative actions performed during the window, and that the change ticket links to this evidence.

Plan the renewal calendar and owner

A third-party certificate expires on the date the issuing CA sets, and FreeIPA will not renew it for you. Assign a named owner, put the expiry date on a shared calendar, and schedule the renewal request well before the deadline. Confirm the lead time your external CA needs, and whether the owner's role has a backup person who knows the procedure.

Verify backups restore with the new chain

Run ipa-backup after the change and test a restore in an isolated environment to confirm the restored server presents the new certificate and trusts the issuing chain. The backup documentation warns that restoring outdated data into an active replica topology can break replication, so restore tests should never run against production replicas. Confirm which servers hold the renewal role and where the backups are stored.

Test revocation and expiry alerts

Confirm that monitoring raises alerts before the new certificate expires, and that your team knows how a compromised server certificate would be revoked and replaced. Test the alert path with a staging certificate that expires on a short schedule. Ask your external CA how revocation is requested and how quickly its status information is published.

Limits to confirm in your environment before committing

Before you commit to this change, confirm the exact FreeIPA release running in your environment and the command options that release supports. The researched facts available for this page do not give the syntax for ipa-cacert-manage install or ipa-server-certinstall, nor do they say how long either step takes, so treat any command you read in a blog post as unverified until you check it against the FreeIPA documentation for your version. Confirm also whether your certificate authority issues certificates with the extensions the Web UI and LDAP need: a server certificate must carry the right key usage and extended key usage values, and the subject alternative names must match the names your users and clients actually type. Ask the issuer for a sample certificate and inspect it before you order anything for production.

Next, map the trust store behavior of every client operating system that touches IdM. Machines that rely on the system trust store will need the new issuing CA added and refreshed, and some applications keep their own bundles, so a machine that looks correct at the operating system level can still reject the certificate in a browser, a Java runtime or a database client. Confirm how your Linux, UNIX and Windows fleets update trust, who owns that update, and whether it can run automatically. Also confirm the order in which you will update replicas and the renewal master. The renewal master handles certificate renewal and CRL publication by default, so the order of changes and the timing of the cutover deserve a written runbook that you rehearse on a non-production topology first.

Finally, find every application outside FreeIPA that pins the current certificate or its fingerprint, including load balancers, monitoring agents, backup jobs, reverse proxies, appliances and scripts that call the LDAP or HTTPS endpoints with hard-coded trust. Pinned systems will fail at cutover unless you update them first or plan a short overlap period. Record each one, its owner and the change window it needs. Then confirm with your CA team how the replacement certificate will be renewed, because a third-party certificate will not renew on the schedule FreeIPA uses for its own certificates.

Questions buyers ask before replacing FreeIPA certificates

What drives the cost and effort of replacing FreeIPA web and LDAP certificates?

The main drivers are the number of FreeIPA servers and replicas that must be updated, the number of enrolled machines that must trust the new issuing CA, how long your CA takes to issue and return certificates, and how many change windows your operations process allows. Each server is a separate certificate installation and restart, so a larger topology adds steps and verification. Enrolled machines add the most work when they are not managed by configuration tooling, because each one needs the updated CA trust. One-time costs cover planning, the CA request, the change itself and testing. Recurring costs come from renewal, which stays with your team unless you contract support. When you request a quote, ask for the server and replica count, the machine inventory method, the CA process owner and the expected change windows, and ask how each is priced.

Can our own team replace FreeIPA certificates without a partner?

Yes, if your team has Linux administration skills, working knowledge of PKI and certificate chains, and a tested rollback plan. The work involves generating or obtaining a server certificate with the right subject and alternative names, adding the issuing CA with ipa-cacert-manage install, applying the certificate with ipa-server-certinstall, and running ipa-certupdate on every affected machine. Teams without FreeIPA experience usually benefit from a rehearsal on a non-production replica first. Ownership should be settled before the change: one person should own the CA request, one should own the server change, and one should own machine updates and verification. A partner can take on any of these roles under a written scope.

How long does a third-party certificate replacement take?

Duration depends on your environment and on the lead time of your certificate authority, which is outside your control and varies by organization. The server work itself can be short once certificates are in hand, but planning, change approval, rehearsal and the machine rollout often take longer than the certificate installation. Machines that are managed centrally can be updated quickly, while unmanaged hosts take more coordination. This page does not give a duration because none is supplied for this topic. Ask any provider for a timeline that separates CA lead time, server changes, machine updates and verification, and ask which of those steps depend on your change calendar.

What do we need to provide before the work starts?

The work needs four things from your side. First, access to the corporate or public CA, or a named contact who can issue certificates and return the chain. Second, a current inventory of FreeIPA servers, replicas, DNS names used for LDAP and the web UI, and the enrolled machines that trust them. Third, a change window that covers the server restarts and the machine updates, plus an agreed rollback procedure. Fourth, named owners for the CA, the FreeIPA servers, the client fleet and the sign-off. Ask whether your environment uses configuration management for client updates, since that changes how the machine step is scheduled and checked.

What does a fixed-scope engagement cover for this change?

A fixed-scope engagement is agreed in writing before work starts and lists the scope, deliverables and timeline. For this change, a reasonable scope includes reviewing the current certificate state, preparing the certificate requests with your CA, installing the issuing CA and server certificates, updating the affected machines, testing the web UI and LDAP connections, and documenting the result and rollback steps. Items you should confirm in the written scope are whether machine updates are included or only described, whether non-production rehearsal is included, which servers are in scope and what happens if the CA lead time delays the window. DeployOpen plans, implements, documents and supports self-hosted platforms in your own infrastructure. It does not issue certificates or audit reports, so your CA and your auditors remain responsible for those.

Does the replacement include renewal of the third-party certificates?

Renewal is a separate, recurring task and is not included in a one-time certificate replacement unless the written scope says so. Third-party certificates expire, and renewal means obtaining a new certificate from your CA, installing it on the FreeIPA servers and verifying the web UI and LDAP services afterward. If the issuing CA also changes, machines may need updated trust as well. Ask the provider whether the scope covers a renewal procedure, a documented calendar, and a handover to your team. Ongoing support, upgrades and continuous testing are available as retainers, so renewal can be covered under a separate agreement if you want the work carried forward.

How DeployOpen scopes and delivers FreeIPA certificate changes

DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including FreeIPA. For a change to the Web UI and LDAP certificates, we agree the scope in writing first, then build and verify the change on your servers and your enrolled machines before handing it over.

How we scope

We confirm which FreeIPA servers, replicas and client machines will receive the new web and LDAP certificates before work starts.
We document the issuing CA chain, certificate subject names and validity you will supply, and who approves each one.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any change is made.

How we build

We add the issuing CA with ipa-cacert-manage install on each server in the topology, then verify the trust store on every server.
We install the new Web UI and LDAP certificates with ipa-server-certinstall, using a tested sequence that keeps services running.
We run ipa-certupdate on each enrolled machine and check that clients accept the new chain before the change goes wider.

How we hand over

You receive a written record of the scope, the certificate changes made, the verification steps and the results on each server.
We document the renewal path for the third-party certificates, including who renews them, how, and where the reminders go.
We walk your operations team through rollback steps and the commands they will need if a later renewal fails.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so renewals and FreeIPA upgrades can be handled over time.
We can review certificate expiry dates and client trust stores on a schedule you agree, and report what needs action.
Any follow-on work on CA chains or service certificates is scoped in writing as a separate, fixed-scope change.

Replacing FreeIPA web and LDAP certificates with third-party certificates