How FreeIPA service certificates with certmonger fit your TLS estate
Services on Linux hosts need TLS certificates that are renewed before they expire, and an expired certificate can stop a web server, LDAP client or database connection without warning. FreeIPA can issue those certificates from its integrated Dogtag certificate authority, so the question for your team is less whether FreeIPA can sign them and more who requests them, where the private key lives, and how renewal is tracked after the first issue. This page covers that workflow end to end: generating a certificate signing request (CSR) on the service host, submitting it with ipa cert-request, letting certmonger track the certificate and renew it automatically, and managing the same lifecycle through the Ansible ipacert module.
The design choice that matters most is where the private key is generated. With certmonger, the key stays on the service host and only the CSR leaves it, which keeps key custody with the team that runs the service. Your estate will still need an inventory of which hosts hold which certificates, which services reload when a certificate changes, and which principals are allowed to request each profile. Those decisions connect to CA ACLs and certificate profiles, which are covered on sibling pages, so this page assumes they are settled or will be settled alongside the build.
DeployOpen plans and implements this work inside your own infrastructure, including the request workflow, tracking configuration and renewal checks. DeployOpen prepares systems and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and your auditor will need to review the controls for your environment. Before scoping, confirm with your own team which FreeIPA release your servers run, since behavior differs between 4.x versions, and check the FreeIPA About page for the components your deployment depends on.
Which certificate request method fits which host
This table compares manual CSRs, ipa cert-request with certmonger tracking, and the Ansible ipacert module on who runs each method, how it repeats across a fleet, how renewal behaves and where it fits. Read each column as one option, then match it to the host's ownership and change pattern. Most teams end up using certmonger for long-lived service hosts and reserve manual requests for exceptions.
| Decision factor | Manual CSR with ipa cert-request | certmonger tracking with getcert | Ansible ipacert module |
|---|---|---|---|
| Who runs it | An administrator on the host or a workstation, one request at a time | The service host's administrator, once per certificate, with the daemon handling later renewals | Automation owners who maintain playbooks and the control node with FreeIPA credentials |
| Repeatability at fleet scale | Low, since each CSR, submission and installation is a manual step | Moderate, since the same tracking command can be scripted across hosts | High, since one role can request and track certificates for many hosts from one definition |
| Renewal behavior | None built in; someone must submit a new request before expiry | Automatic renewal through the tracking daemon, provided the host can reach FreeIPA and the key stays on the host | Depends on how the playbook is run; confirm the schedule and tracking behavior in your own test environment |
| Private key location | Generated on the service host, which keeps the key local | Generated on the service host and tracked locally | Generated on the managed host through the module; confirm where keys are created in your version |
| Typical fit | One-off certificates, unusual hosts, or troubleshooting a single request | Long-lived service hosts where the operator wants renewal without a separate pipeline | Large or frequently rebuilt fleets, and environments where certificate setup is already code |
| Main failure point | Missed expiry because no one owns the renewal date | Renewal fails silently if the host loses access to FreeIPA or the tracking state is lost during a rebuild | Playbook drift, or credentials on the control node with broader rights than the task needs |
| What to confirm before choosing | Who owns the renewal calendar and where CSRs are archived | Which services reload after renewal and how the post-renewal hook is written | The ipacert module version in your distribution and how it is tested before production runs |
Setting up certificate issuance and renewal for a service
This sequence takes a service host from enrollment to a tracked TLS certificate that FreeIPA issues and certmonger renews, with the service reloaded and checked after each renewal. It ends with a test handshake that confirms the certificate the service presents is the one FreeIPA issued.
Confirm the host and service principal exist
Before any certificate is requested, confirm that the host is enrolled as an IPA client and that the service principal, such as HTTP/web01.example.com, exists in FreeIPA. Run
ipa host-showandipa service-showagainst the principal from a machine with a valid Kerberos ticket. Creating the service principal withipa service-addis also the point where you decide which hosts may manage its certificate. You are done when both commands return the expected entries and the host's keytab contains the service key. If either is missing, fix enrollment first, because certificate requests for an unknown principal fail.Generate the private key and CSR on the host
On the service host, generate the private key and certificate signing request so the private key never leaves the machine. Keep the key readable only by the service account and the root user, for example under
/etc/pki/tls/private/. Include the host name as the subject alternative name and set the common name to the service principal's host name. Check the result withopenssl req -inon the CSR file to confirm the subject and SAN entries are correct. You are done when the key file has restrictive permissions and the CSR lists the exact names clients will use to connect.Submit the CSR with ipa cert-request
Submit the CSR to FreeIPA with
ipa cert-requestand name the principal the certificate belongs to. The request is evaluated against the certificate profile and CA ACLs in place, so a denied request usually points to a missing rule rather than a fault in the CSR. Save the certificate FreeIPA returns to a file alongside the key, and record the serial number from the output. Confirm the result withopenssl x509 -noout -subject -issuer -dateson the certificate, checking that the issuer is the IPA CA and the names match the CSR. You are done when the certificate is valid and its names match what the service will present.Start tracking the certificate with certmonger
Register the key, certificate and CA with certmonger using
getcert start-trackingand the IPA CA helper, with the principal and the paths for the certificate and key. Certmonger then watches the certificate and submits renewal requests itself when it nears expiry. Use the nickname option if you want a stable name for later commands. Confirm the tracking withgetcert list, which should show the file paths, the CA, and a status of MONITORING. You are done when the entry exists and the status is MONITORING rather than a request or error state.Confirm tracked status and the renewal path
Check that certmonger can actually renew this certificate before relying on it. Run
getcert listfor the entry and read the expiry date, the post-save command and the CA it will use. Then rungetcert resubmiton the entry to confirm a renewal request reaches FreeIPA and returns a new certificate. Confirm that the host can reach the IPA servers that handle renewal and that the principal's permission to request certificates still applies. You are done when a manual resubmit completes and the status returns to MONITORING with a new serial number.Configure the service to reload on renewal
A renewed certificate on disk does nothing until the service reads it again. Set a post-save command on the tracking entry with
getcert modifythat reloads or restarts the service, for example a reload of the web server or the daemon that uses the certificate. Keep the command narrow so a failed reload is visible in the logs. Then trigger a renewal withgetcert resubmitand confirm the service restarted cleanly. You are done when the entry lists the post-save command, a test renewal runs it without error, and the service logs show it loaded the new certificate.Verify the service with a test handshake
Finish by testing what clients will see. Run
openssl s_clientagainst the service's host name and port, using the IPA CA certificate as the trust anchor, and confirm the verification result is OK. Compare the serial number and expiry in the presented certificate with the output ofgetcert list. Repeat the test from a client that trusts the IPA CA through its enrolled configuration. Confirm the connection succeeds and record the result in your change log. You are done when the handshake verifies, the serial matches the tracked certificate, and the check is repeatable after the next renewal.
What certmonger renews and what the renewal master does
certmonger watches every certificate you track and asks FreeIPA for a new one before the current certificate expires. The daemon runs on the service host, holds the key and the tracking request, and submits a renewal to the CA when the certificate nears its end of life. The service keeps running on the old certificate until certmonger writes the new one to the tracked path. That means renewal depends on two things working at once: the host must reach a FreeIPA server that can sign, and the service must pick up the new files. Check getcert list on each host for the status and expiry of every tracked certificate, and treat any entry that is not in the MONITORING state as an open item.
FreeIPA's backup documentation states that the first server handles certificate renewal and CRL publication by default. This server is the renewal master, and its health therefore matters for every tracked certificate in the deployment, not only for its own services. If it is down, unreachable, or restored from an outdated backup, renewals can stall without any visible error on the service side until the certificate is close to expiry. Confirm which server holds the renewal role in your topology, include it in your health checks and alerting, and check the current behavior and any role-transfer steps against the documentation for your FreeIPA version, since these details have changed across 4.x releases.
certmonger can also run a post-renewal hook that reloads or restarts the service after a new certificate is saved. Without that hook, the service keeps serving the expired certificate even though the renewal succeeded. Write the hook as a small, idempotent script, reference it in the tracking request, and test it on a non-production host by forcing a renewal with getcert resubmit and confirming that the service presents the new serial number. Repeat the test after each change to the service configuration or operating system, because a hook that works once can fail silently after a package update or a path change.
Security considerations for service certificates
A certificate issued by FreeIPA is only as trustworthy as the process around it. The cards below cover the decisions that determine who can obtain a certificate, where its private key lives, and how a compromised or failing certificate gets caught and contained.
Key generation and file permissions
The private key should be generated on the service host and never leave it. Only the CSR travels to FreeIPA, so the CA never holds the key. Check that the key file is owned by the service account, readable only by that account and root, and stored outside world-readable directories. Confirm that backups and configuration management repositories do not copy key material. Certmonger keeps the key and request in its own tracking records, so review those permissions too.
CA ACLs for who may request
CA ACLs decide which principals may request which certificate profiles and from which issuing CAs. Without them, any enrolled host or user may be able to request a certificate for a name it does not own. Review each ACL so that a host can only request certificates for its own fully qualified domain name and services it runs. Check the admin bypass permission during audits, because it can override these restrictions.
Serial number and profile choices
Use the certificate profile that matches the service, such as the default service profile for server certificates, rather than a broad profile that adds extensions the service does not need. Confirm validity periods and key usage in the profile before the first request. FreeIPA 4.13.0 made random certificate serial numbers the default, which removes predictable serials from new issuance. Confirm the behavior of any older CA installed before that release.
Protecting the renewal master and backups
The first server in the topology handles certificate renewal and CRL publication by default, so it is the most sensitive server for certificates. Restrict administrative access to it and place its ipa-backup archives under the same controls as the CA signing material. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so restore procedures should be tested on an isolated system first.
Revocation for compromised hosts
When a host is compromised or decommissioned, its certificates must be revoked, not just left to expire. Revocation reasons are recorded and the CRL must be published for relying services to see the change. Certificate hold is the only reversible state, so use it for suspected compromise while an investigation runs. Document who can trigger revocation and how the team will confirm that the CRL has been published.
Monitoring for failed renewals
Certmonger renews tracked certificates automatically, but a renewal can fail because of a stopped service, a changed DNS name, or an ACL that no longer matches. Monitor the tracking status and certificate expiry dates on every host, and alert well before expiry. Ask your team to confirm how renewal failures reach an on-call engineer, since an expired service certificate causes an outage that looks like an application fault.
Questions teams ask before issuing certificates with FreeIPA
How much effort does issuing service certificates through FreeIPA take?
The effort scales with the number of services, the number of hosts that run them, and the reload work each service needs when its certificate changes. A small set of services on a few hosts is a short, contained project. Each service adds a CSR, a certmonger tracking request, a profile and CA ACL decision, and a tested reload hook. The CA ACL review is often the largest hidden item, because someone must decide which principals may receive which profile from which CA. Ask any partner to break its quote down by service count, host count and hook count, and to state which of those items are included in the fixed scope.
Can an in-house team issue FreeIPA service certificates without outside help?
Yes, many in-house teams do this successfully, provided they already run Linux administration and have someone who understands how FreeIPA enrolls hosts and issues certificates. The core tools, certmonger and ipa cert-request, are standard parts of the FreeIPA stack. The risk sits in the details: getting the reload hooks right for each service, keeping CA ACLs narrow, and testing renewal before the first certificate expires. If your team has not run a renewal cycle before, a short review of the design and the first few services is often the cheapest way to avoid surprises.
What does the work need from our team before it starts?
Four inputs matter most. First, every host that will request certificates must be enrolled in FreeIPA, so it has a host principal and can receive certificates for its names. Second, DNS must resolve each service name to the right host, because the certificate subject and subject alternative names must match what clients connect to. Third, each service needs a named owner who can confirm the hostname, the reload action and the acceptable maintenance window. Fourth, you need change windows agreed in advance for the first rollout and for any service that cannot reload without a restart. Ask your partner to list these inputs in the written scope so gaps show up before work begins.
How does Ansible automation change the effort?
Ansible shifts effort from repeated manual steps to a one-time build of reusable roles. The ipacert module can request and track certificates from playbooks, so each new service follows the same pattern instead of a hand-built procedure. The upfront cost rises because you must write, test and review the playbooks, and you must agree on variables for hostnames, profiles and reload actions. The ongoing cost falls because adding a service becomes a variable change plus a review. Confirm the module version and its supported options against the FreeIPA release you run, because automation is only as stable as the module behind it.
What recurring work remains after go-live?
Recurring work is smaller than the build, but it does not disappear. Someone must review the CA ACLs when services, owners or teams change, and remove access that no longer applies. Certificates renew automatically through certmonger, but you should still monitor tracking status and confirm that each reload hook ran after renewal. Service owners must report new services, changed hostnames and retired hosts, so tracking requests are added and removed. Finally, FreeIPA itself needs upgrades and backups, and the renewal master must be kept healthy. Ask any partner whether ongoing monitoring and upgrades are covered by a retainer or a separate agreement.
What goes wrong most often with certmonger renewals?
Most failures come from a few causes. A reload hook that fails silently leaves the service serving an expired certificate even though certmonger renewed the file. A hostname missing from the request means clients reject the certificate after renewal. A CA ACL that was never granted causes the request to be denied, which can go unnoticed until the old certificate expires. Finally, a renewal that depends on a host or DNS entry that changed owners can break without warning. Test each service with a forced renewal in a non-production environment, and alert on tracking status rather than waiting for a client to fail.
Does issuing certificates through FreeIPA meet our audit requirements?
FreeIPA records certificate requests and issuance, and CA ACLs give you a documented policy for who may receive which certificate. That helps you prepare evidence for a compliance assessment. However, DeployOpen prepares systems, controls and evidence for assessments but does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make that judgment. Confirm with your auditor which records they will sample, such as request logs, ACL reviews and renewal history, before you finalize the design.
When a partner helps with certificate automation
Bring in a partner when the certmonger work stops being a single host exercise and becomes a fleet problem. The first case is breadth: a FreeIPA realm that issues certificates to web servers, LDAP-backed applications, mail relays, load balancers and internal tools will have a different certmonger pattern on each one. Each service needs its own certificate principal or host entry, its own key path and ownership, its own --post-save-cmd or equivalent reload hook, and its own check that the service actually picked up the new certificate. Mapping those per-service decisions across dozens of hosts is slow to do well and easy to leave half finished, and the gaps only show up when a certificate is close to expiry.
The second case is reload hooks that touch production. A renewal hook that restarts a web tier, reloads a proxy or rotates a database listener runs unattended, often at a time nobody is watching. Designing those hooks means deciding what runs after a failed renewal, how a partially updated cluster is detected, and whether a hook can be rolled back without an outage. Ask any prospective partner to show how they would test a hook against a staging copy of your service, and how they would prove that a renewed certificate was loaded rather than just written to disk.
The third case is renewal master placement across sites. Renewal and CRL publication run on the first server by default, so the decision of where that role lives, how replicas in other datacenters reach it, and what happens during a site outage is an architectural decision, not a configuration detail. Pair that with an external CA, where the signing chain and renewal cadence are set by someone outside your team, and the design needs an owner for each step. Confirm with the vendor and your own topology notes how the renewal master role is assigned before you agree on who changes it.
How DeployOpen scopes and delivers certificate work
The sequence below turns a certificate need into a written scope, a set of tracked service certificates and a handover that your own team can run after the engagement closes. Each step ends with a check you can review before the next one starts.
Inventory the services that need certificates
We list every service that terminates TLS or authenticates with a certificate, including the host, the service account that reads the key, the expected DNS names, the reload command and the owner who approves changes. This is done with your platform and application owners, and the output is an inventory table your team keeps. The step is complete when each entry has a named owner and a confirmed set of subject alternative names.
Confirm the CA profile and issuance rules
We check which FreeIPA certificate profile each service should use, which CA issues it, and which CA ACLs allow the requesting principal or host to receive it. Where your organization has an approval process or a particular validity expectation, we record it in the scope rather than assume it. The step closes with a written list of profile and ACL decisions that you approve before any host is changed.
Agree the written scope and deliverables
Most engagements are fixed-scope, so the services, hosts, deliverables, handover documents and acceptance checks are agreed in writing before work starts. The written scope also states what is out of scope, such as certificates for third-party appliances or changes to the CA hierarchy. Your procurement team receives a quote that follows directly from this scope. The step is complete when both parties sign the scope document.
Build and test tracking on a non-production host
We configure certmonger tracking requests on one representative host, generate the key and CSR locally, and submit the request with ipa cert-request. We then confirm the certificate chain, the key permissions, the service reload hook and the post-renewal behavior before using the same pattern elsewhere. Your team reviews the test results. The step is complete when a tracked certificate is issued, installed and reloads the service without manual steps.
Roll out tracking and the Ansible pattern
Using the agreed inventory, we apply the same tracking pattern across the remaining hosts, either with direct configuration or with the Ansible ipacert module where your team already manages hosts with Ansible. Changes go through your normal change process, and each host is checked for a tracked status and a valid certificate. The step closes with a host-by-host status report that shows what is tracked and what still needs attention.
Verify renewal and revocation handling
We check how renewal behaves before the first real expiry, including what certmonger does on failure, which hosts are expected to reload, and how a compromised certificate would be revoked through the normal FreeIPA process. Your team sees the renewal dates and the test outcomes. The step is complete when the renewal and revocation checks are recorded with the expected behavior for each service.
Hand over documentation and runbooks
We deliver the inventory, profile and ACL decisions, host configuration notes, the Ansible role or configuration files, and a runbook for adding a new service or handling a failed renewal. Your staff walk through the runbook, and we note any open items. The step is complete when your named owners confirm they can add a host and read the renewal status without DeployOpen involvement.
Decide on optional renewal monitoring
After handover, you can choose whether to keep renewal monitoring under a retainer, which covers periodic checks of tracked certificates and help with failures. The retainer scope, cadence and fees are set in its own written agreement, and it is optional. If you keep your own monitoring, the handover documents list what to watch. The step is complete when you have recorded the monitoring decision and the named contacts for it.
