Running FreeIPA without a CA

Running FreeIPA without a CA: when the integrated Dogtag CA is not the right fit

A CA-less FreeIPA deployment is one where you do not let FreeIPA issue certificates from its own Dogtag certificate authority and instead supply certificates from a corporate PKI or a public CA. Teams choose this when they already run a certificate process that auditors, browsers and endpoint management trust, and they want FreeIPA for identity services without adding a second internal CA to operate. The choice changes where certificates come from, not what FreeIPA is. According to the FreeIPA About page, FreeIPA combines 389 Directory Server for users, groups, hosts and policies, MIT Kerberos for single sign-on, the Dogtag certificate system, and SSSD on clients. Skipping the integrated CA leaves the directory, the KDC and the client roles in place, so your work moves to supplying, installing and renewing the certificates those components depend on.

Before you commit, map which certificates your deployment needs. LDAP over TLS, the Web UI and the Kerberos PKINIT path each need a certificate that clients trust, and each has its own install step and its own renewal date. The exact install options, the self-signed restriction and the handling of the CA certificate vary by release, so confirm them against the documentation for the version you run before you plan the build. The FreeIPA About page is the right starting point for the component model, and the installation guide for your release is the authority on flags and behavior. Ask your identity team which trust anchors your clients already have, because a third-party chain that machines do not trust will break enrollment and login in ways that look like Kerberos faults.

The main cost of this model is renewal work that FreeIPA would otherwise automate. When Dogtag issues a certificate, FreeIPA tracks it and renews it on the first server. When an external authority issues one, your team owns the expiry calendar, the request, the install and the propagation to every server and client that trusts it. Decide who receives expiry alerts, how renewal requests reach the external CA, and how a missed renewal is detected before services stop. Also plan for the time it takes to test a renewed chain on a replica before the production servers are changed. These are the operational duties that the rest of this section describes in more detail.

Which certificate model fits your FreeIPA deployment

This table compares the integrated Dogtag CA, an externally signed CA chained to a corporate root, and a CA-less install that uses certificates you supply. Read each column as a model and each row as a question you must answer before choosing. The main takeaway is that fewer built-in CA features mean more renewal and revocation work on your team.

Question	Integrated Dogtag CA	Externally signed CA	CA-less with supplied certificates
Who issues certificates	FreeIPA's Dogtag CA issues certificates for hosts, services and users	Dogtag issues from an intermediate chained to your corporate or AD root	Your existing CA or a public CA issues each LDAP, HTTP and PKINIT certificate
Who renews certificates	FreeIPA renews its own CA and tracked service certificates	The CA certificate needs a manual renewal request; service certificates follow the integrated model	Your team tracks expiry and renews every certificate outside FreeIPA
Automation for service certificates	certmonger tracking and automatic renewal for enrolled services	certmonger tracking still works for certificates issued by the chained CA	Confirm with your release whether certmonger can track supplied certificates; plan manual renewal until you do
Role of the first server	Handles certificate renewal and CRL publication by default, so it must be backed up and kept healthy	Same default role as the integrated CA; confirm the renewal master setting for your release	No CA role to manage, but the first server's settings still need review for any remaining CA-related jobs
Revocation and CRL	FreeIPA revokes and publishes the CRL itself	Revocation runs through the chained CA; confirm how the CRL is published to clients	Revocation happens at your external CA, and clients must trust its CRL or OCSP endpoints
Main trade-off	Least operational work, but the CA is a platform you must back up, patch and recover	Trusted corporate chain, with a manual CA renewal and more coordination	Keeps FreeIPA out of CA duties, but adds ongoing renewal work and the risk of missed expiry

What you must supply for LDAP, HTTP and PKINIT

Without the integrated Dogtag CA, every certificate-dependent service in FreeIPA needs a certificate you obtain and install yourself. The four items below show what each service presents to clients, who issues the material, and where trust must be configured before anything else works.

LDAP listener certificate

The 389 Directory Server listener presents a server certificate that clients use when they negotiate TLS for LDAP. Your certificate must carry the server's fully qualified host name in its subject or subject alternative name, and the full chain up to your issuing CA must be available to the server. Confirm in the install and certificate documentation for your release how the directory is pointed at the certificate and key, and whether the chain must be supplied as a separate file. Check the chain before first start, since a missing intermediate is the most common cause of failed client binds.

Web UI and HTTP certificate

The Apache front end that serves the web UI and the IPA API needs a certificate for the server's host name, issued by a CA that browsers and command-line clients on your network already trust. Because the built-in CA is absent, renewal is a manual calendar item owned by your team, not an automatic process. Confirm the exact file paths and the method for replacing the certificate for your release, and test that the API still answers after the swap, since the command-line tools rely on the same trust.

PKINIT certificate for Kerberos

PKINIT lets Kerberos clients authenticate with X.509 certificates, such as smart cards, instead of passwords. Your KDC needs a certificate that the domain controller side can present, and the issuing CA must be listed as trusted for Kerberos certificate logins. Confirm with the FreeIPA documentation for your release whether the KDC certificate is taken from the same store as the web certificate, and whether certificate mapping rules must match the subject names your CA issues. Plan this with smart card owners before enabling the option.

Client trust store distribution

Every enrolled host, workstation and application that talks to FreeIPA must trust the root and any intermediate that signed your server certificates. Without the built-in CA, the usual step of pulling the IPA CA chain from the server does not give you the trust you need, so you must push your corporate root to each system through your configuration management. Confirm for each distribution which trust store path and update command apply, and test an LDAP bind and a Kerberos login from a clean client before you call the rollout complete.

Why the self-signed restriction changes what you can run

A self-signed-only certificate position means that the certificates presented by your IdM services are not issued by a CA that clients already trust, so every consumer that validates TLS or Kerberos-related certificates must be told explicitly what to accept. In practice, the services that break first are the ones clients connect to automatically: the LDAP endpoint that SSSD and other clients query, the HTTPS endpoint of the Web UI and API, and any PKINIT path where a client presents or validates a certificate for Kerberos sign-in. Browsers, sudo-less automation tools, container workloads and third-party applications that embed their own trust stores will reject these certificates unless someone deliberately adds trust. Confirm, for the release you run, exactly which of these paths enforce validation, which default trust locations they read, and whether any of them offers a supported exception.

Because the trust anchor is not a public or corporate root, it must be distributed to every enrolled machine and to every application host that talks to IdM. That distribution is ongoing work: each new client, each new service, each rotated certificate and each re-enrolled host needs the right root or intermediate in the place its software reads. Plan an inventory of trust stores by operating system and application, a method to push updates, and a check that confirms each machine trusts the same chain. Ask your team to document which hosts were never enrolled through the normal path, since those are the usual sources of certificate errors that appear weeks after go-live.

This restriction is the strongest practical reason to supply a proper CA chain from the start. A chain issued by your corporate root or an intermediate you control gives you one trust anchor to distribute, one renewal process to schedule, and one set of records to show how certificates are issued and validated. Auditors reviewing identity or certificate controls will ask how the chain is built, who holds the signing authority, how each certificate is checked against its issuer and revocation status, and how trust reaches every host. Prepare those answers before the assessment. DeployOpen can help you design and document the evidence, but the auditor decides whether the control meets the requirement.

How to set up a CA-less FreeIPA deployment in order

This sequence takes a FreeIPA deployment with its internal certificate authority disabled to a state where every service presents a certificate you can trace to a trusted issuer, every client trusts that issuer, and every renewal date is recorded. Each step ends with a check you can run before moving on.

Decide the certificate model for each service
Before requesting anything, the architecture owner lists every certificate the deployment needs: the LDAP service, the HTTP service for the Web UI and API, the Kerberos KDC for PKINIT, and any other services that will present certificates to clients. For each one, record who issues it, which trust chain clients will use, and whether the certificate is public or private. Confirm with the FreeIPA docs for your release how a CA-less install handles the CA certificate and which certificates the installer still generates itself. The step is done when this list is approved and each row has an owner. Use a written list, not memory, as the reference for the rest of the sequence.
Prepare a certificate signing request for each service
For each entry on the list, generate a private key and a certificate signing request on the host that will hold the key, so the key never leaves that host. Include the fully qualified names clients will use in the subject alternative names, and for the KDC include the Kerberos principal and realm details your release documents for PKINIT. Store keys with restrictive file permissions. The check is that every CSR decodes correctly and lists the expected names, and that the key-to-CSR match is recorded. Confirm the exact request format and any required extensions with the documentation for your release and with the CA team that will sign them.
Obtain signed certificates and install them
Submit each CSR to the issuing authority, which may be a corporate root, an enterprise issuing CA, or a public CA, and receive the signed certificates and their chains. Install each certificate and key on its service using the replacement procedure your FreeIPA release documents for the Web UI and LDAP, and follow the KDC steps for PKINIT. Restart only the affected services in the order the documentation specifies. The check is that each service loads its new certificate without errors in its logs, and that the certificate's subject, issuer and validity period match the request. Keep the original configuration files until verification in step six passes.
Distribute the CA chain to every client
Deliver the root and any intermediate certificates to every enrolled Linux host, every container image that talks to FreeIPA, and every application server that validates LDAP or HTTPS. On enrolled hosts, add the chain to the system trust store using the method your distribution and FreeIPA release document, then refresh the store. Track the list of hosts with a configuration management tool so new enrollments pick up the chain automatically. The check is that a client which has never seen the chain fails validation, and the same client succeeds after the chain is installed. Hosts outside FreeIPA, such as network appliances, need their own check.
Verify the LDAP TLS handshake
From a client host and from any application that binds to LDAP, open a TLS session to the FreeIPA LDAP port and inspect the presented certificate. Confirm that the subject names match the names clients use, that the chain validates against the trust store without an override, and that the certificate is not expired. Then perform an authenticated bind with a test account to confirm the session works end to end. Repeat from each replica, because each one serves its own certificate. The step is done when every server and every client path shows a clean handshake and a successful bind. Record the commands and output in the change record.
Verify HTTPS and Kerberos PKINIT
Test the Web UI and API over HTTPS with a browser and a command-line client that does not use an insecure override, and confirm the certificate chain validates. For PKINIT, obtain a Kerberos ticket with a smart card or certificate-based credential issued against your chain, then use that ticket to reach a Kerberized service. Confirm the principal, realm and ticket lifetime are the ones you designed. The check is a successful browser session, a successful API call, and a successful PKINIT login from a client that trusts only your chain. Confirm the exact PKINIT configuration keys and tools with the documentation for your release before testing.
Record renewal dates and assign owners
For every certificate on the list, record the issue date, expiry date, issuer, serial number, file locations, the service that uses it, and the named owner who will renew it. Set reminders well before expiry, and decide who handles the renewal request, the installation, the client chain update and the post-renewal verification. Because FreeIPA does not renew externally issued certificates for you, this record is the control that prevents an outage. The check is a reviewed register in which every certificate has an expiry date, an owner and a tested renewal path, and at least one person outside the original team has confirmed it.

The renewal work you take on without the integrated CA

Without the integrated Dogtag CA, FreeIPA no longer renews the certificates it serves, publishes revocation lists or distributes trust for you. Each card below is a recurring job your team inherits, and the effort grows with the number of hosts, services and separate CAs issuing certificates.

Track every service certificate expiry

Keep one inventory of every certificate that FreeIPA's Web UI, LDAP listeners, Kerberos KDC and application services present, with its issuing CA, subject, and expiry date. Without an inventory, a lapse usually surfaces as a login failure rather than a scheduled task. Confirm which monitoring tool alerts on expiry and who receives the alerts, and test that the alert fires before the certificate expires.

Reissue certificates before they lapse

Each third-party certificate needs a new CSR, a signed certificate from your external CA, and an installation step on the server that uses it. Plan this as a change with a named owner and a window, because the replacement must be in place before the old one expires. Confirm whether your CA issues renewals automatically or requires a manual request, and how long that request takes.

Redistribute the CA chain to every machine

When an external CA issues or rotates an intermediate or root, every enrolled client, server and application trust store must receive the new chain. FreeIPA's own trust distribution does not reach hosts that rely on their own bundles. Inventory which machines trust the FreeIPA-facing CA, define how the chain reaches each one, and verify it on a sample host after each change.

Handle revocation outside FreeIPA

Without the integrated CA, revoking a compromised or retired certificate happens at your external CA, and FreeIPA does not publish a revocation list for it. Decide who may request revocation, how departed staff and lost devices are reported, and how relying systems learn about revoked certificates through their own CRL or OCSP checks. Confirm the revocation endpoints your external CA publishes.

Test renewal on a non-production replica

Rehearse every renewal and trust change on a replica or lab copy before production, using a recent backup. The FreeIPA backup documentation notes that the first server handles certificate renewal and CRL publication by default and that restoring an outdated backup into an active topology can break replication. Confirm which server is the renewal master in your topology and whether any of these jobs moved to it.

How operations change for single-site and multi-site topologies

In one datacenter with few replicas, the topology is small enough that one team usually knows every server's role. Without an internal CA, each server that presents a certificate for LDAP, HTTP or PKINIT carries its own supplied certificate and its own renewal date, so the renewal workload grows with the number of servers.

Replica count: The deployment recommendations advise at least two to three replicas in each datacenter. A single site with two or three replicas sits inside that guidance, and a single replica leaves no redundancy for renewal or recovery.
Certificate renewal: Record the expiry date and the installed file paths for every server and client-facing certificate. Confirm the renewal steps for your release before the first expiry date, since each host needs the new certificate and the trust chain updated.
Backups: Schedule backups on at least one server and store copies off the host. Choose between full backups and online data-only backups according to your recovery targets.
Replica roles: With no internal CA, no replica is required to run PKI. If you run DNS, place it on at least one replica according to the recommendations, and keep the servers dedicated to FreeIPA.

Before go-live, list every server that presents a certificate and name the person responsible for renewing each one.

Limits to confirm before you commit to a CA-less design

A CA-less design moves certificate duties from the built-in Dogtag CA to your team and your external CA. Before you commit, confirm which FreeIPA features still depend on the integrated CA, which certificate-based logins your users rely on, how each upgrade changes certificate handling, and whether your release carries current security fixes.

Features that need the integrated CA

Some FreeIPA functions assume Dogtag is present, including issuing certificates through ipa cert-request, tracking renewals with certmonger, running sub-CA and CA ACL workflows, and publishing CRLs. Confirm feature by feature which of these your team uses and which the vendor documentation says require the CA. The backup documentation notes that the first server handles certificate renewal and CRL publication by default, so check where those roles sit in your topology.

Certificate-based authentication paths

Smart card logon, certificate mapping and PKINIT depend on which certificates the Kerberos KDC and clients trust, and on how those certificates map to users. Confirm that the third-party issuing chain covers every certificate type these paths use. Check that your mapping rules still match the subject or SAN fields your external CA writes, then test one smart card login and one PKINIT login from a Linux client before changing anything else.

Certificate handling across 4.13

The 4.13.0 release notes list random certificate serial numbers by default and the first beta of a new web UI, among other changes. Read the notes for the exact release you plan to run, then check how your external certificate workflow handles serial numbers, the new defaults and any web UI certificate steps. Repeat this check on every upgrade, because your externally issued certificates sit outside the built-in renewal path.

Confirm security fixes are applied

The 4.13.4 release notes, dated July 9, 2026, list two CVE fixes, including LDAP access control flaws that could let unauthenticated clients obtain credentials, along with hardened authentication checks across the API. A CA-less design does not remove these exposures. Confirm that your servers run the patched release and that every replica does. Record the installed version on each server and compare it with the notes before go-live.

Named owners for each renewal

Each third-party certificate for LDAP, the Web UI and PKINIT has its own expiry date, and you own the renewal steps for every one of them. Confirm who owns each renewal, which system tracks expiry dates, and how the replacement reaches every server and client that trusts the chain. Write the steps down with a named owner and rehearse them once in a test environment before the first certificate expires.

What teams ask before they run FreeIPA without a CA

How much more effort is a CA-less FreeIPA install than one with the integrated CA?

A CA-less install usually takes more upfront and more ongoing effort, because your team or your partner must supply and track every certificate that the integrated Dogtag CA would otherwise issue and renew. The install itself is the smaller part. The larger items are obtaining certificates for the LDAP, HTTP and PKINIT roles, distributing the issuing chain to every enrolled machine, and building a renewal process that outlasts the people who set it up. Ask for the effort split in writing: install work, certificate sourcing, chain distribution, and recurring renewal tasks, each listed separately.

What drives the effort of running FreeIPA without a CA up or down?

The main drivers are the number of server and service certificates, how many client machines must trust the chain, and how many external systems depend on FreeIPA certificates. Effort also rises when your corporate CA process is slow, manual or undocumented, and when you run several replicas that each need the same certificate material. It falls when your CA can issue automated certificates, when you have a standard list of hostnames and roles, and when your configuration management can push trust changes. Ask a prospective partner how each driver affects their estimate.

What does the work need from our own staff?

Plan for staff who understand your corporate PKI, your DNS naming, and your Linux fleet. Someone must own the request process with your certificate authority team, approve each certificate request, and accept responsibility for expiry dates. Engineers need working knowledge of FreeIPA, Kerberos and certificate formats, and someone must run the trust distribution on every enrolled host. Confirm named owners for these roles before work starts, and record who will take over when a person leaves.

Can a small internal team run a CA-less FreeIPA deployment on its own?

A small team can run it if it has at least one engineer comfortable with PKI, one who can coordinate with the corporate CA owners, and time reserved for renewals. The risk is concentration: a single person who knows the certificate layout becomes a single point of failure. Before deciding, check whether your team has tested a renewal, restored from backup, and rebuilt trust on a client machine. A written runbook and a partner review at a fixed point can close that gap. DeployOpen can plan, implement and document this work in your infrastructure, and ongoing support is available as a retainer.

How long does CA-less setup take, and what determines it?

Duration depends on the number of certificates to source, the speed of your corporate CA approvals, the size of the FreeIPA topology, and the number of client systems that need the new chain. Organizations with a responsive CA team and a short host list move faster than those that need new approval workflows. No general timeline is supplied for this work, so ask for a duration in the written scope, with each milestone tied to a dependency such as CA approval, test enrollment and production cutover.

What should a quote for CA-less FreeIPA include?

A quote should list the fixed-scope deliverables in writing: the FreeIPA servers and roles in scope, the LDAP, HTTP and PKINIT certificate sources, the chain delivery method, the client machines covered, and the test and rollback steps. It should separate one-time work from recurring work, such as renewal tracking, upgrades and testing. Ask which party is responsible for each certificate request, what happens when a CA approval is late, and what documentation and handover you receive. Assumptions about your existing CA should appear in the scope so they can be checked.

How is certificate renewal scheduled in a CA-less design?

In a CA-less design, renewal is your process, not FreeIPA's. Each third-party certificate has its own expiry date, and FreeIPA will not renew it automatically. Schedule renewals well before expiry, track every certificate in one inventory, assign an owner for each, and test the replacement on a non-production replica first. Include the chain update on every enrolled client in the same runbook. Ask your partner to deliver a renewal calendar and a tested procedure as part of the handover.

When should a team reconsider a CA-less FreeIPA design?

Reconsider the design when renewal tasks are missed, when the corporate CA cannot meet the issuance pace your services need, or when staff turnover leaves no one who can run the process. It is also worth revisiting when you add sub-CAs, device certificates, or many new services, since each adds certificates to manage. Review the decision after any certificate expiry incident, before a major FreeIPA upgrade, and when your compliance assessment asks how certificate lifecycle is controlled. Your auditors make the assessment, and DeployOpen prepares the systems and evidence for them.

How DeployOpen scopes and delivers a CA-less FreeIPA deployment

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a CA-less FreeIPA deployment, we start from a written scope that names every certificate you will supply, who renews it, and how the renewal work is handed to your team.

How we scope

Inventory every LDAP, HTTPS and PKINIT certificate endpoint and its current issuer
Record which third-party CA issues each certificate and who holds the renewal process
Agree the renewal calendar, alert thresholds and owner for each certificate in writing
Confirm the self-signed restriction applies to your servers, clients and any PKINIT use

How we build

Set up FreeIPA servers and replicas in your infrastructure with the agreed certificate inputs
Install third-party certificates and CA chains on the web UI and LDAP services
Configure client trust so every enrolled machine accepts the supplied chain
Test LDAP, HTTP and PKINIT authentication against each certificate before cutover

How we hand over

Deliver runbooks for each certificate, including renewal steps, replacement and rollback
Document the monitoring checks and expiry alerts your team should keep running
Walk your administrators through renewal on a test certificate in your environment
Provide the written record of scope, configuration and test results for your audit file

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover
Review certificate expiry status and renewal readiness on an agreed schedule
Plan FreeIPA upgrades around certificate changes and retest affected trust paths
Confirm with your certificate provider the renewal lead times that apply to your CA

Running FreeIPA without a CA