How FreeIPA ACME automated internal certificates replace manual requests
FreeIPA uses the ACME server built into Dogtag PKI, so internal clients can request and renew TLS certificates from the FreeIPA CA without an administrator filing a request each time. Teams need this when they run many internal web services, reverse proxies or service hosts whose certificates expire on a schedule that manual requests cannot keep up with. The protocol is ACME as defined in RFC 8555, which lets a client prove control of a name and then obtain a certificate automatically. The service is not on by default: you enable it per server with ipa-acme-manage enable and turn it off with ipa-acme-manage disable, so the decision belongs in your server design, not only in the client configuration.
Before you enable it, decide which servers will host the ACME endpoint, because the FreeIPA design ties the service to the individual server rather than to the whole topology. Confirm that the CA role is present on those servers and that clients will reach the directory at <domain>/acme/directory. Ask your vendor or check the FreeIPA ACME design page for the current list of supported clients and any prerequisites for your release, since the design names Certbot and the Apache mod_md module as examples rather than a complete list. Also confirm how the ACME endpoint is reached from networks that cannot resolve internal names, because a client that cannot reach the directory will fail silently into the manual process you were trying to remove.
Automation shifts the work to ownership and verification. Someone must decide which hosts may request certificates, who approves names and which challenge type fits each network: http-01 needs the client to serve a file on port 80 that the CA can reach, while dns-01 needs the client to create a DNS record and therefore touches your DNS design. Plan a test on one non-production host first, check that renewal runs unattended, and confirm that certificate profiles, lifetimes and revocation still match your PKI policy. Manual requests do not disappear overnight, so keep the old path documented until every consuming service has moved.
Challenge types and client options, and when each fits
This table compares the http-01 and dns-01 challenges and the Certbot and mod_md clients for FreeIPA ACME issuance. Read each row against your network and DNS setup, then use the final rows to decide what to confirm before you choose.
| Option | What it needs | Where it fits |
|---|---|---|
| http-01 challenge | The ACME validation request must reach port 80 on the host requesting the certificate, so the name must resolve to that host from the network the CA validates from. | Internal web servers that already accept HTTP from the validating network and do not need a DNS write step. |
| dns-01 challenge | Write access to the DNS zone so the client can publish a temporary TXT record, plus a DNS server that accepts the update. | Hosts without inbound HTTP, servers behind a proxy, and names whose DNS is managed centrally in the IdM zone. |
| Certbot client | Certbot installed on the host, registration against the ipa-ca ACME directory, and a plugin or webroot setup for the chosen challenge. | General Linux servers where you want a standard ACME client and scripted renewal. |
| mod_md (Apache) | The Apache mod_md module, configured with the ACME directory and the names it should manage. | Apache HTTP Server hosts that should renew certificates within the web server itself. |
| Service and host names | Each name in the certificate must resolve correctly to the host or DNS record used for validation. | Confirm naming first, because a mismatch between DNS and the requested name is a common reason validation fails. |
| Network path to the CA | The client must reach the ipa-ca hostname over HTTPS, and the CA must be enabled on the server that answers. | Confirm which IdM server runs ipa-acme-manage enable and whether that server is reachable from each client subnet. |
| Confirm before choosing | Whether your firewall allows port 80 from the validation path, whether your DNS servers accept dynamic updates, and whether your clients trust the FreeIPA CA chain. | Ask your platform team and check the FreeIPA ACME design page and the Certbot and mod_md documentation for the versions you run. |
Enabling ACME on a FreeIPA server and requesting a first certificate
This sequence turns on the ACME service in the FreeIPA CA, confirms the ipa-ca directory answers, and proves that a client can obtain a certificate from it. It also gives you a tested rollback path before any production host depends on the service.
Confirm the server runs the Dogtag CA
An administrator logs in to the candidate server and checks that it is an IdM server with the certificate authority role, since ACME is provided by the Dogtag PKI instance inside FreeIPA. Run
ipa config-showagainst the domain and confirm the CA server role is present on this host. If the server is a client-only enrollment or a replica without the CA role, stop here and choose a server that runs the CA. Done when the host is listed as a CA-capable IdM server and you have recorded its fully qualified name for the next steps.Enable the ACME service on the server
On the chosen CA server, a FreeIPA administrator runs
ipa-acme-manage enableas root. This turns on the ACME server implemented in Dogtag for that server only, so the change does not spread to other replicas automatically. Record the time and the change ticket in your own change log before running the command. Done when the command completes without errors and you can move on to the status check.Verify the ACME status and directory
Run
ipa-acme-manage statuson the same server to confirm the service reports as running. Then, from a separate client machine on the network, request the directory at the ipa-ca host name under the /acme/directory path for your domain, and confirm that it returns a JSON document listing the ACME endpoints. If the request fails, check DNS resolution for the ipa-ca name, firewall rules and the trust chain on the client. Done when the directory responds over HTTPS from the client network.Register a test client with Certbot or mod_md
On a non-production test host enrolled in FreeIPA, install Certbot or configure the Apache mod_md module, and point it at the ipa-ca ACME directory URL. Trust the FreeIPA CA certificate on that host so the client accepts the directory's TLS certificate. Run the client's account registration step, which creates an ACME account with the server. Done when the client reports a registered account and the account appears without errors in the client log.
Request and validate a first certificate
Ask the test client for a certificate for a host name in your internal domain and select the challenge type that fits your network, http-01 when the name reaches the client over port 80 or dns-01 when you control the DNS zone. The client completes the challenge, and the FreeIPA CA issues the certificate. Done when the client saves the certificate and key files on disk and the certificate's subject and issuer match your FreeIPA CA.
Confirm the issued certificate in IdM
On the IdM side, run
ipa cert-findor the certificate search in the web UI for the host name you requested, and confirm the new certificate is recorded against that host. Check that the serial number and validity dates match the files on the test client. Keep a note of the issuance so renewal monitoring can track it later. Done when the certificate is visible in IdM and matches the client copy.Disable the service for rollback when needed
If the test fails or the service must be withdrawn, run
ipa-acme-manage disableon the same CA server, then runipa-acme-manage statusto confirm it is stopped. Repeat the directory request from the test client and confirm it no longer answers. Certificates already issued stay valid until their normal expiry, so rollback affects new requests only. Done when status reports the service as disabled and the directory no longer accepts new requests.
Which FreeIPA servers should run ACME
A single FreeIPA server with its integrated Dogtag CA is the simplest case. Every ACME request lands on that one host, so there is no question of routing or of which server should answer. The ACME service is enabled on that server with ipa-acme-manage enable, and the ACME directory is then reached at the ipa-ca name for your domain. The trade-off is that the same host also carries certificate renewal, CRL publication and every identity service, so an outage there stops both logins and certificate issuance.
- Enablement: Confirm the ACME service is enabled on the only CA-capable server and that clients resolve the
ipa-caname to it. - Single point of failure: Plan how you would restore certificate issuance if this host is down, since no other server can answer.
- Backups: Include the CA data in your backup routine, because losing it affects every certificate the CA issued.
- Client trust: Make sure every client that requests certificates trusts the internal CA chain.
- Capacity: Confirm that one server can handle the expected volume of renewals across your hosts.
Before relying on this layout, check that the ACME directory answers from every network segment that needs certificates.
In a replicated topology, more than one server can run the CA and the ACME service. The design enables ACME per server, so you decide which replicas expose the directory. Note that the first server handles certificate renewal and CRL publication by default. Because of this, the choice of which server is first determines where renewal traffic and CRL work concentrate, even when ACME requests are spread across several hosts.
- Per-server enablement: Enable ACME only on replicas that are intended to serve it, using
ipa-acme-manage enableon each one. - Renewal and CRL role: Confirm which server is the first CA server and whether it is the right host for renewal and CRL publication.
- Name resolution: Decide how the
ipa-caname maps to one or more servers, and test failover from a client's point of view. - Replication limits: Follow the project's topology guidance on replicas per site, including the advice to run PKI at least once per datacenter if used.
- Backup order: Restoring an outdated backup into an active topology can break replication, so plan restores against the whole topology.
Before you go live, check which server answers ACME requests from each site and what happens when the first server is taken offline.
Some organizations run FreeIPA with a CA that is not fully internal to the IPA topology, for example a CA whose signing is handled by an external authority. In these cases, the ACME service still belongs to the Dogtag system that FreeIPA uses, so the design questions shift. You need to confirm which Dogtag instance issues certificates, whether it can be enabled for ACME in your installation, and which party controls renewal, CRL publication and the signing keys. Treat these as items to verify with your own installation and your CA policy rather than as assumptions.
- Signing authority: Document which party signs the CA certificate and who approves changes to it.
- ACME availability: Confirm with your installation whether the ACME service is available and enabled in your CA setup.
- Renewal ownership: Identify who renews the CA and who publishes the CRL, since this may not be the first FreeIPA server.
- Policy alignment: Check that issued certificate profiles match the policy your external authority requires.
- Change control: Record every enablement or routing change, because the external party may need to be informed.
Before designing around an external CA, ask your CA administrator and the vendor documentation for your environment to confirm the supported ACME configuration.
Security and operational considerations for ACME-issued certificates
Automated issuance removes the manual request step, so the controls that used to sit in a ticket workflow now sit in the ACME configuration, the challenge design and the backup process. The six cards below cover where those controls matter most for FreeIPA ACME service for automated internal certificates.
Challenge exposure on port 80 or DNS
An http-01 challenge needs the requesting host to answer on port 80, and a dns-01 challenge needs write access to the zone that holds the validation record. Either path can be abused if it is reachable by the wrong party or if credentials are shared widely. Confirm which challenge type each client uses, limit the network path to the validation endpoint, and scope DNS update rights to the specific records needed. Review the design on the FreeIPA ACME design page before choosing.
Which clients may request names
ACME lets any client that completes a challenge obtain a certificate for the names it proves control of, so the name policy must be checked against the host and service model. Decide which hosts may enable ACME clients, which domains they may request, and who administers the enable and disable switch. Confirm in your environment how FreeIPA certificate profiles and host ownership apply to ACME requests before you open the service to application teams.
Lifetime and renewal monitoring
Certificates issued through ACME are short-lived by design, so renewal must succeed on every cycle or services fail when the certificate expires. Monitor renewal runs, alert on failed attempts, and track the expiry of certificates that front critical services. Ask the team that owns each client to confirm the renewal schedule and the reload step after renewal, since a successful renewal that does not reload the service still causes an outage.
Backup and restore effects on replicas
The FreeIPA backup documentation warns that the first server handles certificate renewal and CRL publication by default. Restoring an outdated backup into an active replica topology can break replication, which can leave ACME state and issued certificates inconsistent across servers. Plan restores as topology events, confirm which server holds the CA renewal role, and test a restore on an isolated copy before you rely on it for recovery.
CA key protection
Every certificate issued through the ACME service is signed by the Dogtag CA, so the CA signing key is the most sensitive asset in the design. Restrict root access to the CA servers, limit who can administer certificate profiles, and decide early whether the CA key must sit in a hardware security module for your assurance needs. Confirm with your security team how key custody, backups of CA material and administrator access are documented before go-live.
Audit of issued certificates
Automated issuance can produce many certificates quickly, and the record of who requested what must remain reviewable. Keep the CA issuance log, the list of enabled ACME servers and the changes to enablement under change control, and review them on a set schedule. Ask the platform team which logs are retained, where they are stored and how an auditor would query issuance for a given host or name.
Questions teams ask before enabling FreeIPA ACME
How much effort does enabling FreeIPA ACME take?
The effort depends mostly on how many servers request certificates, how those servers are configured today, and which challenge type each one can satisfy. Enabling the service on the CA-hosting server with ipa-acme-manage enable is a small step on its own. The larger work is inventory and client changes: identifying every service that currently gets a certificate by hand, deciding which of them can answer an http-01 challenge over port 80, which need dns-01 because they sit behind a load balancer or on hosts with no inbound web access, and then configuring Certbot or mod_md on each one. Each client added after the first typically repeats the same validation, renewal and reload testing. Ask any partner to split its estimate into the CA change, the DNS or web prerequisites, and the per-client work, so you can see which part grows with your estate.
Can an internal team enable FreeIPA ACME without outside help?
Yes, an experienced FreeIPA team can enable the service and onboard a first set of clients using the FreeIPA ACME design and the Certbot and mod_md documentation. The questions that usually decide whether to bring in help are not about the command itself. They are whether your team already runs FreeIPA's Dogtag CA with clear ownership of renewal and CRL publication, whether you can change DNS records or web server configuration on the systems that need certificates, and whether you have a tested rollback plan for the CA server. Teams with a small number of services and a stable DNS setup often manage this in house. Teams with many heterogeneous clients, or with no one who has built a CA change before, often find a fixed-scope engagement with written deliverables reduces the risk of an outage.
What access and inventory does an ACME rollout need from us?
Before any quote is final, you should be able to provide four things. First, administrative access to the FreeIPA servers that host the Dogtag CA, with a change window agreed for enabling the service. Second, control over the DNS zones that the certificates cover, so that dns-01 records can be created and removed, or confirmation that http-01 traffic can reach each client on port 80. Third, a client inventory listing every hostname, the web server or service that uses the certificate, the operating system, and who owns it. Fourth, a list of certificates that are still issued by hand and the systems that depend on them. Teams that cannot produce this list early usually discover missing clients during rollout, which lengthens the work.
How long does an ACME rollout usually take?
No researched duration for FreeIPA ACME rollouts is available, so treat any timeline as unverified until it is tied to your own inventory. The factors that set the duration are the number of clients, how many need dns-01 changes, how many services have a reload step that needs a maintenance window, and how many owners must approve changes. Ask for the schedule to be broken into phases: a pilot on one or two low-risk hosts, a validation period where renewals are observed, and a staged onboarding of the remaining clients. Ask the vendor or partner to state which of these phases are fixed in the written scope and which depend on your change approvals.
Does FreeIPA ACME replace our existing certificate requests?
It can replace manual requests for the services you move to it, but it does not remove the need for an inventory of what you currently run. ACME automates the request, validation and renewal cycle for a certificate that a client can obtain through an http-01 or dns-01 challenge. Certificates for systems that cannot run an ACME client, appliances with fixed certificate import workflows, and some services with unusual validation rules may stay on the current process. A realistic transition keeps the manual process running for those systems while the automated clients are validated, then retires the manual step only after renewals have succeeded through a full cycle. Confirm with your security team how existing certificates will be revoked or left to expire, and whether any policy requires a change to the issuance process.
What should a quote for FreeIPA ACME include?
A quote should follow from a written scope and list each piece of work separately. Ask for the FreeIPA server changes needed to enable and disable the ACME service on each CA-hosting server, the DNS or web prerequisites for each challenge type, the Certbot or mod_md configuration for each client group, and the testing that proves a renewal works end to end. Ask whether backups of the CA and a documented rollback path are included, how renewal failures will be monitored after go-live, and what handover material you receive. Recurring costs, such as monitoring, upgrades or retainer support, should be stated separately from one-time work. DeployOpen does not publish a price list, and a quote follows from the written scope agreed before work starts.
What changes for teams that request certificates by hand today
The main shift is that the server asks for its own certificate instead of an administrator filing a ticket, waiting for a signed CSR, and copying files into place. With the ACME service enabled on a FreeIPA server, a client such as Certbot or the Apache mod_md module registers with the <domain>/acme/directory endpoint, proves control of the name through an http-01 or dns-01 challenge, and renews on its own schedule. Request and approval work does not disappear, but it moves into the design phase: someone decides which hosts may request which names, which challenge type each host can satisfy, and who owns a failed renewal at two in the morning. Confirm these decisions with your security and operations leads before the first client is pointed at the directory.
Automation does not remove the work around the certificate itself. Every service that loads a certificate from disk needs a reload or restart step after renewal, and that step must be tested on each platform, whether through a Certbot deploy hook, a mod_md setting, or a systemd unit change. Hook scripts need the same change control as any other automation, because a broken hook fails silently until the old certificate expires. Build an inventory before cutover that lists every certificate in use, its subject names, the hosts and services that consume it, the owner, and the expiry date. The inventory is also the list you need to check against the ACME design, which describes the per-server enable and disable commands, ipa-acme-manage enable and ipa-acme-manage disable, and confirm which servers in your topology actually run the service.
Certificates issued by hand do not need to be replaced on the first day. They can keep running until their normal expiry while new hosts and renewals move to the ACME flow, and the two sets coexist without conflict because each certificate is independent of how it was requested. The practical risk is a service that is migrated to ACME but still points at a file managed by a manual process, so each migrated service should be checked for a single source of truth for its certificate. Plan the cutover host by host, keep the manual request path available until the inventory is empty of manually managed entries, and ask your FreeIPA support provider or your own platform team to confirm how the ACME service behaves in your specific server version before you rely on it for production renewals.
How DeployOpen scopes and delivers FreeIPA ACME
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, including FreeIPA. For ACME issuance, we start from your server inventory, certificate naming and client tooling, then build and hand over the Dogtag ACME service in your FreeIPA deployment under a written, fixed scope.
How we scope
- Inventory which servers, services and clients will request certificates through the ipa-ca ACME directory.
- Agree in writing which challenge types, http-01 or dns-01, each host group will use and why.
- Confirm the DNS, firewall and certificate naming constraints that the ACME endpoint must satisfy in your network.
How we build
- Enable the ACME service only on the FreeIPA servers you name, using ipa-acme-manage enable.
- Configure Certbot and mod_md clients on pilot hosts, then test registration and renewal end to end.
- Run negative tests for blocked challenge ports, failed DNS updates and expired account keys before wider rollout.
How we hand over
- Deliver a runbook covering enable and disable steps, client configuration, renewal checks and troubleshooting notes.
- Document the ACME directory URL, client settings and challenge decisions for each host group in a shared reference.
- Walk your platform and security teams through the handover and record which manual certificate requests are retired.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover review of FreeIPA release notes and ACME-related changes before your servers are upgraded.
- Ask any quote to state which items are one-time build work and which recur under a support agreement.
