Installing FreeIPA with an externally signed CA: when your organization needs it
Choose this path when your internal certificates must chain to a root that already exists in your organization, such as a corporate root or a Microsoft AD Certificate Services hierarchy. FreeIPA can be installed with its Dogtag certificate authority subordinate to an external CA, using a two-step process: first generate a certificate signing request from the first server, then have the external CA sign it and install the result. The point of the section is that the decision is made before the first server exists, because it determines who controls the top of your certificate trust.
FFreeIPA bundles the 389 Directory Server, MIT Kerberos, the Dogtag certificate system and SSSD on clients, and Dogtag issues certificates for the realm from a CA that the first server runs. With an external signature, the FreeIPA CA certificate is no longer self-signed. Every client, service and Kerberos principal in the realm then trusts certificates through the chain that ends at your corporate root, so the identity team must agree with the PKI owners on the root's validity, key policy and revocation publication before installation. Ask the PKI owner whether the root can sign a subordinate CA certificate with the path length and extensions your design needs, and confirm this in writing before you start.
Renewal changes as well. An internally self-signed FreeIPA CA renews within FreeIPA, but a CA signed by an external authority needs a new signature from that authority when it nears expiry, so the renewal calendar and the external owner's responsibilities belong in your operating plan from day one. Confirm with the root owner how long they need to turn around a renewal request, who approves it, and where the new certificate is delivered. Also confirm how revocation of the subordinate CA would be handled if the FreeIPA server were compromised, since that event would affect every certificate the CA has issued.
Which CA model fits your FreeIPA install
This table compares the four ways to handle the FreeIPA certificate authority: the default integrated CA, an external root, Microsoft AD Certificate Services as the signer, and a CA-less deployment. Read each row against your root key policy and renewal capacity, then follow the sibling topic named in the last row. The main takeaway is that every external option moves some renewal work to your team.
| Model | When it fits | Who holds the root key | What your team must renew |
|---|---|---|---|
| Integrated self-signed CA | Greenfield deployments with no corporate root requirement, and labs where chaining is not required | The FreeIPA CA itself, on the first server | The CA chain and CA certificate are managed by FreeIPA, but you must plan renewal and confirm the first server's role as renewal master |
| External root chained to corporate PKI | Organizations that require every internal certificate to chain to a corporate root or policy CA | Your corporate or policy CA, which signs the FreeIPA CA certificate | The FreeIPA CA certificate, which cannot renew automatically and needs a CSR round trip (see the renewal topic) |
| Microsoft AD Certificate Services as signer | Windows-centric estates where AD CS already issues trust for domain members and you want one chain | The AD CS root or subordinate CA, under your Windows PKI administration | The FreeIPA CA certificate through the ms-cs CSR flow, plus any AD CS template and validity changes on the Microsoft side |
| CA-less with third-party certificates | Teams that use a public or corporate CA for LDAP, HTTP and PKINIT and do not need FreeIPA to issue anything | Your external CA, outside FreeIPA | Every service certificate, LDAP, HTTP and PKINIT certificate, and the renewal workflow (see the CA-less topic and the third-party certificate topic) |
Setting up the external CA install step by step
This sequence takes a FreeIPA server from a prepared host to a working internal CA that chains to your corporate root or Microsoft AD Certificate Services. Each step ends with a check so you can stop and fix problems before the next stage begins.
Prepare the server and DNS
The platform or security engineer confirms the host meets the FreeIPA prerequisites for your release, sets a fully qualified hostname that matches the realm and IPA domain, and creates forward and reverse DNS records that resolve correctly from the server itself. Time synchronization and firewall rules for the FreeIPA services are checked at the same time. The step is complete when name resolution forward and reverse returns the expected values and the host clock is synchronized. Confirm the prerequisite list for your release in the FreeIPA installation documentation before you start.
Run the first install stage with the external CA option
The engineer runs the first stage of the server installer with the option that tells it the CA will be signed externally, so the installer stops after generating the certificate signing request for the CA rather than completing the install. Record the exact option name and flags from the installation documentation for your release, because they change between versions. The step is complete when the installer exits with a request file written to disk and no services are yet running as a finished CA. Keep the installer log, since it helps if the second stage fails.
Select the CSR type that matches the signer
The engineer chooses the CSR format that matches the signing authority. A generic CA takes the standard request format, while Microsoft AD Certificate Services requires the ms-cs type. Choosing the wrong type is a common cause of rejected or malformed requests, so confirm the accepted values for your signer and release in the documentation. The check is that the request file header and the template expected by your signing team agree with the selected type before anything is submitted.
Submit the request and retrieve the full chain
The PKI administrator submits the request to the corporate root or subordinate CA and requests a CA certificate using the template approved for intermediate or subordinate CAs. Ask the signing team to return the issued certificate together with every intermediate and the root in a single chain file. Confirm the certificate is marked as a CA, that its basic constraints allow signing, and that its key usage includes certificate signing. The step is complete when you hold a signed certificate and a complete chain file that verifies against your trusted root.
Run the second install stage with the signed chain
The engineer returns the signed certificate and chain to the server and runs the second installer stage, pointing it at the files with the option named in the documentation for your release. The installer then configures the directory, Kerberos, and the Dogtag CA using the external certificate. Expect this stage to take longer than the first and to write detailed logs. The step is complete when the installer reports success and the IPA services start without errors. Save the output so the second stage can be audited later.
Verify the CA certificate and chain
The engineer checks that the CA certificate on the server matches the one issued by the signer, that the issuer and subject fields show the expected chain, and that the full chain validates against the corporate root with a standard verification tool. The ipa cacert or certificate listing command can confirm what the server publishes, and an enrolled test client should trust the CA after running the client trust update. The step is complete when a test client trusts the chain without warnings and the verification output shows no missing intermediates. Confirm the exact commands and expected output for your release in the documentation.
Corporate root CA or Microsoft AD Certificate Services as the signer
A corporate root or intermediate CA is the most flexible signer. In the two-step flow, the first run of ipa-server-install with --external-ca generates a certificate signing request for the FreeIPA CA. Your CA team signs that request under a policy that allows a subordinate CA certificate, then returns the issued certificate together with every certificate above it in the chain. The second run consumes that material to finish the install.
- Confirm the CA can sign subordinate CAs: The returned certificate must carry CA basic constraints, and your policy must allow it to act as a signing CA for the FreeIPA domain.
- Return the full chain in the right format: Ask for the issued certificate and each intermediate and root certificate, in the format your install step expects. A missing intermediate is the most common cause of a failed second step.
- Agree on validity and key details in writing: Ask the CA team how long the signed certificate will be valid and which key settings they require, because the FreeIPA CA must be renewed by hand later.
- Keep the request and response paired: Store the CSR, the signed certificate and the chain together with the install record so that a mismatch can be traced quickly.
- Plan the trust rollout: Every enrolled client and service must trust the new chain, so schedule the distribution of the root to hosts before users are affected.
Before starting, confirm with your CA owner the exact signing policy, the chain format and the renewal process, then check the current FreeIPA installation documentation for the options your release supports.
When the signer is Microsoft AD Certificate Services, the CSR must be produced in a form AD CS accepts. FreeIPA's external CA workflow supports a CSR type for Microsoft certificate services, which you select with the ms-cs option when generating the request. The AD CS administrator then issues the subordinate CA certificate from a template that permits CA certificates, and returns the chain that the FreeIPA install needs.
- Select the `ms-cs` CSR type: Use the option that tells FreeIPA to format the request for AD CS, and verify that your installed release offers it before planning around it.
- Get a suitable template from the AD CS administrator: The template must be one the administrator intends for subordinate CAs, with validity and key usages that fit a signing CA. Do not reuse a web server template.
- Ask who approves the request: Many AD CS deployments hold CA requests for manual approval, so the administrator must know the request is expected and when it will arrive.
- Request the complete chain: Ask for the enterprise root and any intermediate certificates along with the issued certificate. The root must be trusted by Linux hosts as well as Windows, so plan the distribution.
- Record the template and CA names: Keep the template name, the issuing AD CS server and the validity period in your install record, since renewal depends on them.
Confirm the template, the ms-cs behavior and the chain format with your AD CS administrator and the current FreeIPA documentation before the first run, because the exact options depend on your release and your Windows CA configuration.
Common failures in external CA installs and how to avoid them
Most failed external CA installs trace back to a short list of causes: the wrong request type, an incomplete trust chain, and a certificate that reached one server but not the rest. Each card below names one failure, the symptom it tends to produce, and the check that catches it before it reaches production.
CSR of the wrong type
The certificate request must match what your signer expects. For a Microsoft AD Certificate Services signer, the ms-cs CSR type is the one to generate, not the generic default. Ask the CA administrator which template and request format they will sign, then compare the request you produced against that specification before submitting it. A request that is rejected or issued with the wrong extensions wastes a full round trip with the signing team.
Incomplete chain without intermediates
If your corporate CA issues through an intermediate, the certificate you receive for the FreeIPA CA is only useful with the intermediate alongside it. Install the full chain, from the FreeIPA CA up to the root, and verify it with openssl verify against the root you intend clients to trust. Do not assume the signer's download page delivers everything in one file.
Root certificate missing from clients
Enrolled hosts, browsers and the FreeIPA web UI only trust the FreeIPA CA if the root that anchors it is in their trust stores. A chain that validates on the server can still fail on a Linux client that was enrolled before the root was added. Confirm that the root is present on every client class you run, and that the distribution's trust update step has been applied.
CA certificate installed on one server only
The external CA step runs on the first server, but the result must reach every replica. A replica that still holds the old CA certificate will sign or validate differently from its peers, which shows up as intermittent trust errors. After the install, run ipa-certupdate on each server and each enrolled client, then confirm that all servers report the same CA certificate.
Expired signing material
The external CA certificate and its issuing chain have their own validity periods. If the signer's intermediate or root is near expiry when you install, the FreeIPA CA inherits a short remaining lifetime, and the renewal you planned may fall outside the signer's window. Record every not-after date in the chain before you start, and agree the renewal path with the signing team as part of the design.
DNS and hostname mismatches
The CA certificate and the server certificates it issues bind to hostnames and the IPA domain. A server whose fully qualified name, reverse DNS or DNS alias differs from what the request contains will receive certificates that clients reject. Before generating any request, confirm forward and reverse resolution for each server, and that the names in the CSR match the names clients use to connect.
How the certificate chain reaches clients and replicas
The full chain, from the external root through any intermediate to the FreeIPA CA certificate, has to be trusted on every FreeIPA server and on every enrolled client, or TLS and certificate-based logins will fail in ways that are hard to trace back to the install. Treat chain distribution as part of the install plan, not a cleanup step after the first server comes up. Confirm with your external CA team exactly which certificates make up the chain, in which order they must be delivered, and whether any intermediate will change before the CA certificate expires.
Plan for the first server to carry the most certificate work. By default it handles certificate renewal and CRL publication, so its clock, its access to the signing workflow and its backups matter more than they do on a replica. Before you add replicas, check the FreeIPA backup documentation on what happens when an outdated backup is restored into an active topology, since that is the failure mode that can break replication. Keep the chain files under change control on every server so a replica never starts with a different trust store than the first server.
Use the deployment recommendations to decide where PKI runs. They advise at least one replica per datacenter running PKI when it is used, alongside two to three replicas per datacenter overall. Ask your team to map each datacenter to a PKI-capable replica, then verify after each change that the new replica has the chain and that certificate requests are served there. The FreeIPA deployment recommendations list the current guidance, and your replication and renewal tests should be written against that list, not against memory of an earlier release.
Security and operational considerations for an external CA
Chaining FreeIPA to a corporate CA moves trust, signing authority and recovery responsibility across two organizations. The cards below cover the decisions that connect the CSR, the corporate signing process, the backups you take around the install, and the replica topology that must stay consistent afterward.
Protecting the CSR and key material
The intermediate CA private key is generated on the first FreeIPA server and must never leave it. Only the certificate signing request travels to the corporate CA. Decide how the CSR is transferred, who may handle it, and where the signed chain is returned, and confirm that no copy of the key sits on a workstation, shared drive or ticket attachment. Check file permissions on the server before and after the transfer.
Controlling who can sign
The corporate CA administrator decides the subject name, validity period and extensions that FreeIPA receives. Agree these values in writing before the request is submitted, because a wrong basic constraint or path length can block the install or limit future sub-CAs. Confirm which corporate team owns the signing template and who approves each renewal request.
Backups before and after the install
Take a full backup with ipa-backup before the two-step install begins, so an interrupted run can be rolled back to a known state. Take another backup once the CA is working and the chain is verified on every client. Store both copies off the server, and record which backup corresponds to which CA certificate so recovery does not mix generations.
First server renewal and CRL role
By default, the first server handles certificate renewal and CRL publication for the topology. Decide which server is the renewal master before the install and confirm it is the server you protect, back up, and monitor most closely. Plan how its role will be handed over if the host is retired, because clients and replicas depend on CRLs published from it.
Restoring outdated backups
Restoring an old backup into an active replica topology can break replication, according to the backup documentation. Treat any restore as a topology event: stop writes, decide whether the restore is for one server or the whole deployment, and re-check replication agreements afterward. Write a runbook that names who approves a restore and who checks replication status.
Verifying the chain on every host
A correct install still fails if clients, replicas or applications trust only the old root. After the chain is delivered, confirm that each enrolled host and service receives the updated CA certificates. Keep a checklist of hosts, replicas and integrations, and record the result for each so the final state is documented for audits.
Questions teams ask before installing with an external CA
What drives the effort and cost of an external CA install?
The effort depends mostly on how many parties must act and how much of your PKI already exists. The work splits into three parts: preparing the certificate signing request on the FreeIPA server, having the corporate or Active Directory CA issue a subordinate CA certificate with the right extensions, and then delivering the full chain to every server and client. Costs come from internal PKI staff time, the platform engineers who run the two-step install, and any change window needed on production identity servers. If you are paying a partner, the quote should itemize discovery of your CA templates, the install itself, chain distribution testing and handover. Ask for those items as separate lines so you can see which ones your own team could absorb.
What does the work need from our internal PKI team?
Your PKI team must control the signing side of the process, so their involvement starts before the FreeIPA install. They need to confirm which CA will sign the FreeIPA intermediate, which certificate template fits a subordinate CA, what validity period and path length your policy allows, and how the signed certificate will be returned. For a Microsoft AD Certificate Services root, they also need to pick the correct CSR template type for the ms-cs signing flow. Expect them to review the chain file format and to approve who may request and receive the signed certificate. Agree these decisions in writing before the FreeIPA servers are built, because changing the signing CA later means repeating the signing step.
Can our team install FreeIPA with an external CA without outside help?
Yes, a team with Linux administration and PKI experience can run the two-step install, but the risk sits in the details. The install is done in two passes: the first creates a CSR, and the second completes the installation after you supply the signed certificate and chain. Errors in either pass are hard to unwind because the CA certificate becomes part of every later trust decision. Before deciding, check whether your team has run FreeIPA in production, has access to your CA administrators, and can test client trust on a non-production realm. If any of those are missing, a fixed-scope engagement with a written deliverables list may cost less than a failed install and rebuild.
How long does an external CA install take, and what sets that?
The duration is set by lead time on the signing side, not by the FreeIPA commands themselves. The longest waits are usually approval for the subordinate CA request, the time your PKI team needs to issue the certificate, and the change window for the production servers. Test runs on a staging realm, the number of clients that must trust the new chain, and whether you have replicas that need the chain added also affect the schedule. Ask any vendor or partner for a timeline that lists each dependency separately, and confirm which of those dependencies sit with your organization. Do not accept a single duration without that breakdown.
Can we change the external CA later, and what does that involve?
You can move to a different external CA, but it is a re-chaining project rather than a configuration change. The FreeIPA CA certificate is signed by the original authority, so switching means obtaining a new subordinate certificate from the new CA, installing it, and making sure every client and replica trusts the new root. Certificates already issued from the old chain keep working only while that trust remains in place, so plan renewal and revocation together. Our advice is to settle the signing CA during design, because a later change touches every trust relationship in the environment. Your renewal process should also be documented before go-live, as covered in the sibling topic on renewing an externally signed FreeIPA CA certificate.
What happens to clients when the certificate chain is incomplete?
Clients that cannot build a full path to a trusted root will reject the FreeIPA CA, and services relying on it will fail authentication or TLS checks. Typical symptoms include certificate validation errors when enrolling a host, failing HTTPS calls to the Web UI, and LDAP or Kerberos-related certificate checks that stop working on some systems. Clients may still work on machines that already have the intermediate installed, which makes the fault look intermittent. Confirm during testing that each platform in your estate trusts the complete chain, including the root and the FreeIPA CA certificate, and that the trust store update runs on every client. Repair is slower than the install itself because the fix must reach each machine.
Does an external CA install give us compliance evidence on its own?
No. An external CA install produces configuration and records you can show an assessor, but it does not establish compliance. Independent auditors and certification bodies decide whether your controls meet a given requirement. DeployOpen prepares systems, controls and evidence for those assessments, such as documented signing approvals, chain verification results and the change records for the install, but it does not issue audit reports or certifications. Ask your assessor early which evidence they expect for certificate authority ownership and key handling, so the install produces it from the start.
How DeployOpen works on this
DeployOpen plans, implements, documents and supports FreeIPA inside your own infrastructure, including the two-step external CA install that chains the FreeIPA CA to your corporate root or Microsoft AD Certificate Services. The work starts with a written scope that fixes what the CA chain must trust, where the signing step runs and who approves each certificate handoff.
How we scope
- The written scope names the signing authority, its CSR type and who holds the signing step.
- We record which clients, services and browsers must trust the resulting chain before build starts.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work begins.
- Your quote follows from that written scope, and it should separate one-time install work from recurring support.
How we build
- We run the first install step to generate the CA CSR on the FreeIPA server you control.
- We submit the CSR to your signing CA and check the issued chain against the subject and key details agreed in scope.
- We complete the second install step with the signed certificate and verify the full chain on the primary server.
- We test certificate issuance, renewal settings and client trust on representative enrolled hosts before sign-off.
How we hand over
- You receive a runbook covering the install steps, the chain file locations and the commands used to verify trust.
- We document the failure cases we tested, such as incomplete chains and CA trust gaps on client machines.
- We record who holds the external signing step and how to request the next CA renewal from that authority.
- Handover includes a checklist that your security and compliance teams can review against their own requirements.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial install.
- A retainer can cover post-install checks of chain distribution as clients and new servers are added.
- Changes to the external signing authority or its certificate policy should be scoped as new written work.
- Ask any provider to confirm in writing which steps they perform on your systems and which remain your team's responsibility.
