Revoking FreeIPA certificates and certificate hold

Yes, the account disable should trigger a review of every certificate the person holds, and revocation should follow for any certificate that no longer has a valid owner. Disabling a FreeIPA user account blocks new Kerberos logins, but it does not by itself revoke certificates already issued to that user, so a separate step is needed. Decide in advance which certificate types are revoked immediately (user authentication and S/MIME) and which are reassigned (shared service certificates). Confirm with your identity team whether the HR system can trigger this, or whether it runs as a scheduled reconciliation job.

Plan for four groups: user certificates (smart card and client authentication), device certificates (VPN, Wi-Fi or machine identities issued from a sub-CA), service certificates (TLS for hosts and applications requested through certmonger), and S/MIME certificates for email. Each group has a different owner. A user certificate follows the person, a device certificate follows the hardware, and a service certificate follows the service owner, who may be a team rather than one employee. Record the owner and the issuing sub-CA for each certificate so that a departure maps to a concrete list.

Reconciliation compares who the system of record says is employed and in which role against who FreeIPA says owns each certificate. Export active identities from HR or the identity governance tool, export certificate subjects and owners from FreeIPA, and list the differences. Start with users who are disabled or missing in HR but still hold valid certificates, then check movers whose group memberships no longer match their certificate profiles or CA ACLs. Run the comparison on a fixed schedule and keep the output as evidence. Certificate ownership often lives in subject names that do not match HR identifiers, so agree on a mapping before the first run.

Some identity governance platforms can trigger lifecycle actions from HR events, and that can include calling downstream systems. Whether it can reach FreeIPA certificate revocation depends on the connector, the API calls it supports and your own configuration, so confirm this with the vendor and test it in a lab first. Also confirm which action it takes: disabling the account, revoking certificates, or opening a ticket for a person to decide. For certificate hold or revocation, a human approval step is worth keeping for high-impact certificates such as administrator or signing certificates.

A mover should keep the certificates that still match their new role and lose those that no longer do. Review group membership, CA ACLs and certificate profiles after each role change, because access to a certificate profile is controlled by those rules, not by the certificate itself. A certificate issued for a former role remains valid until it is revoked or expires, so do not rely on the account change alone. Ask the mover's new manager to confirm which certificates are still needed, and document the decision so auditors can trace it.

The departed employee's S/MIME certificate should be revoked with a clear reason, and the mailbox owner should be told that signed mail may show a revoked signer. Encrypted mail sent to the person needs a plan too, because revoking an encryption certificate can stop others from encrypting to that address. Decide whether the organization keeps the private key for recovery of archived mail before revocation, and confirm the retention rule with your legal and records team. Test how your mail clients behave with revoked certificates before you rely on this step.

Cost comes mainly from the staff time to define owners, certificate scope and approval rules, plus any integration work to connect HR or identity governance to FreeIPA. Those costs are largely one-time. Recurring costs include the reconciliation runs, reviews of exceptions and the people who approve high-impact revocations. Costs rise with the number of certificate types, the number of issuing sub-CAs and the number of HR systems involved. Ask any partner for a quote that lists the integration assumptions, the reconciliation schedule and who signs off each revocation, since those decisions drive most of the effort.

The main drivers are the number of certificate types in use, the client platforms that must honor revocation, the number of CRL consumers, and whether revocation must be linked to HR events. Each certificate type needs its own decision about which revocation reasons apply, which events trigger a hold, and who may request a revoke. Every client platform, VPN concentrator, Wi-Fi controller, web server or application that checks CRLs needs to be identified and tested, because a revocation that one consumer ignores is still a live credential for that consumer. An existing HR feed that deprovisions staff makes the departed-staff process largely automatic, while a manual process adds steps, approvers and places where a revocation can be missed. Ask for the work to be listed by certificate type, consumer and trigger before anything is priced.

Yes, a team that already runs FreeIPA and understands its CA roles can handle revocation internally, and many do. The skills involved are knowing the revocation reasons, the difference between a hold and a permanent revoke, how CRLs are published and where they are fetched, and how to verify that a revoked certificate is refused by each consumer. The areas that usually take the most time are not the commands but the process design: agreeing triggers with HR and service owners, documenting approvers, and proving that consumers pick up new CRLs. A partner is most useful when the team lacks PKI operations experience, has no test environment that mirrors production consumers, or needs the process reviewed against an assessment. Your team should weigh its current workload against these gaps before deciding.

The work needs administrative access to the FreeIPA CA and the servers that publish CRLs, including the renewal master, which handles CRL publication by default. It also needs a test environment where revocations can be issued and checked against real client platforms without affecting production users. Named approvers are required for each revocation path, such as a security owner for lost devices and an HR or manager contact for departures. Your team should also provide an inventory of certificate profiles, the services and devices that hold certificates, and any existing offboarding tickets or HR events. Expect time from application owners who must confirm how their systems fetch CRLs and what they do when a fetch fails.

A test environment should reproduce the parts of production that decide whether a revocation takes effect. Revocation is verified at the consumer, so the test setup must include the same CRL distribution paths, the same client platforms and the same validation settings, including whether a consumer treats a revoked certificate as a hard failure. A lab with only FreeIPA servers proves the CA side but not the consumer side. Ask for a written list of which consumers are represented in the test environment and which are verified only by documentation. Also confirm how a restore from backup is tested, because restoring an outdated backup into an active replica topology can break replication, and that test should happen outside production.

A quote follows from a written scope. DeployOpen does not publish a price list, and the quote depends on the scope agreed in writing before work starts. The scope should list the certificate types covered, the revocation triggers (lost devices, departed staff, key compromise, and any others), the approval paths, the CRL consumers to be verified, the test environment to be provided or built, and the documents to be delivered. Ask whether the quote separates one-time design and build work from any recurring work such as periodic reviews of revocation records, updates when new consumers are added, or support. Ask what changes would be treated as a scope change, and how they would be priced.

The one-time work is the design of revocation reasons, triggers and approvals, the consumer verification and the documentation. Recurring work includes reviewing revocation records, checking that new client platforms and services honor CRLs, handling new certificate types, and rerunning verification after FreeIPA upgrades or changes to the CA topology. Staff changes also recur: approvers and HR contacts change, so the approval matrix needs a review cycle. Ask the vendor or partner to state which items are included in a fixed-scope engagement and which would move to a retainer, and confirm who owns each recurring check after handover.

Auditors assess whether the process is defined, followed and evidenced, so the work should produce records of each revocation, approvals and proof that consumers stop trusting the certificate. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make that determination. Before work starts, ask which control objectives your assessor will test, confirm the evidence format the assessor expects, and ask your assessor to review the process design early. Doing this early limits rework and keeps the scope tied to what the assessment will actually check.