Private PKI for public sector

Assessors expect a current, complete list of every certificate the CA has issued, with subject, issuer, serial number, key type, validity dates, owning system and status. In FreeIPA, the Dogtag database and the ipa cert-find output hold this record. In step-ca, the issuance log and the certificate store provide the same data, and an external scanner can confirm that nothing was issued outside the CA. Your team should confirm which system is the authoritative source and how the inventory is reconciled against live endpoints. Independent assessors, not DeployOpen, judge whether the inventory meets the control requirements.

Auditors look for a tamper-resistant record of every issuance, renewal, rejection and revocation, showing who or what requested it, which provisioner or profile applied, when it happened and the outcome. FreeIPA Dogtag writes its own audit and request records, and step-ca logs provisioner-based authorization decisions. Revocation records should show the reason code and the time the CRL or OCSP response changed. Confirm where these logs are stored, how long they are retained, and whether they are forwarded to a central log platform such as Wazuh or a SIEM that your organization already runs. Independent assessors evaluate whether the logs are complete and protected.

A key ceremony record documents how the CA signing key was generated, who witnessed it, which hardware or HSM held it, the scripts or procedures used, and the custody assignments for backup key material. Teams usually keep signed ceremony scripts, witness attestations, HSM initialization logs and a list of key custodians with their roles. For step-ca, the record should show whether keys sit in an HSM, cloud KMS or YubiKey. For FreeIPA, it should show where the Dogtag CA key was created and how replicas were prepared. Your organization should confirm the ceremony standard its auditors accept, because the expected format varies by agency and hierarchy.

Auditors typically review a certificate policy, which states what the CA may issue and to whom, and a certification practice statement, which describes how the CA operates day to day. These documents cover naming rules, key lengths, certificate lifetimes, validation methods, revocation handling, key custody and the roles that operate the CA. They should match the actual configuration. In FreeIPA, certificate profiles and their assigned rules are the evidence to compare against the documents. In step-ca, provisioner definitions and template files serve that purpose. Confirm whether your agency must align with an existing government PKI hierarchy, since that determines the required policy structure and the parent authority's approval steps.

Access to CA administration should be limited to named individuals, separated by duty, and recorded. Assessors look for role assignments, approval workflows for signing and policy changes, and logs of every administrative session. In FreeIPA, administrative roles and privileges are defined in the directory, and access events can be traced through the server logs. For step-ca, administrative access depends on the host, the configuration file permissions and the provisioner keys, so those must be locked down and monitored. Your team should confirm how privileged access is granted and reviewed, and whether a PAM or identity governance tool already manages these roles.

Assessors expect documented backups of CA keys, databases and configuration, plus evidence that restores have been tested in a non-production environment. For FreeIPA, ipa-backup and ipa-restore cover the directory and CA data, and the FreeIPA backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so restore tests should be run in an isolated environment. Keep records of backup dates, storage locations, encryption, test results and the time taken to recover. Confirm with your assessor how often restore tests must run and who must sign off the results.

Auditors look for a record of which CA software versions were running, when security updates were assessed, and when they were applied. FreeIPA is a useful example: release 4.13.4, dated July 9, 2026, fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, and hardened authentication checks across the API. A patch record should show when that release was assessed, tested and deployed to every replica that runs the CA. Your team should confirm the internal deadline for critical fixes and whether vulnerability scans cover the CA servers, since assessors will ask for both the scan results and the change tickets.

Independent assessors, such as the agency's Inspector General, an accredited assessor or an external auditor, judge whether the CA controls meet the applicable requirements. DeployOpen does not issue audit reports, attestations or certifications. Within a fixed-scope engagement, DeployOpen can prepare the CA configuration, the logging and backup setup, the access model and the evidence described above so that your assessors can review it. The scope, deliverables and timelines are agreed in writing before work starts. Ask any partner to show which evidence they will hand over and which parts remain your responsibility.

The main cost drivers are the key storage you choose, the number of platforms that need automated certificates, the depth of the CA hierarchy, and the volume of documentation your assessors will expect. Hardware security modules or a cloud KMS add hardware or service fees and operational work for key custody. Each platform that must enroll automatically, such as Linux hosts, Kubernetes clusters, network devices or applications, adds integration effort. A deeper hierarchy with separate offline root and issuing CAs adds ceremony planning and more evidence to produce. Ask any bidder to break its quote down by these components so you can see which ones your scope actually includes.

One-time costs usually include design, the root key ceremony, initial hardware or KMS setup, the first platform integrations, migration from any existing CA, and the policy and evidence package. Recurring costs include HSM or KMS service fees, licenses or support for the software you run, staff time for certificate operations, monitoring of expiry and revocation, periodic key ceremonies for issuing CAs, and patching and upgrades. Retainers for ongoing support, upgrades and testing are available from DeployOpen, and they are priced separately from the initial fixed-scope work. Ask the quote to show both columns separately, with the recurring items stated per year.

The agency needs to supply the inputs that decide the design. These are the existing certificate policy or the government PKI hierarchy it must align with, a current inventory of systems that use or need certificates, named system owners who can approve changes, and the key custody rules that apply to CA keys. Change windows for the platforms being integrated, access to test environments, and a decision-maker who can accept the root key ceremony plan are also required. Missing items usually show up later as rework, so confirm these inputs in the written scope before work begins.

Often yes, but only if the operating model is designed for it. Staff need to handle issuance policy changes, renewals, revocation requests, CRL or OCSP publication, backups, upgrades and key ceremonies on a schedule. For Linux estates, FreeIPA runs as a multi-server topology that requires its own operational discipline, including replica planning and careful backup and restore. For automation, step-ca with ACME and provisioners is operated like any other service. Before handover, check that named staff have the skills, that runbooks exist for routine and emergency tasks, and that a support retainer covers the gaps.

Most DeployOpen engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before work starts. A written scope for a PKI engagement should list the CA hierarchy to be built, the key storage method, the platforms to be integrated, the documents to be produced, the test and cutover approach, and the acceptance criteria. It should also name what is excluded, such as platforms not listed, audit reports or certifications, which DeployOpen does not issue. The quote follows from this written scope, and DeployOpen does not publish a price list. Any change to the scope should go through a written change request.

Check the replica layout first, because FreeIPA's deployment recommendations advise at least two to three replicas in each datacenter and at least one replica per datacenter running the PKI if you use it. Confirm that the first server, which handles certificate renewal and CRL publication by default, is protected and backed up, since restoring an outdated backup into an active topology can break replication. Also confirm the licensing and support model, since FreeIPA is GPL-3.0-or-later with no paid edition of its own, and plan how you will apply security releases such as 4.13.4. Ask your implementer to demonstrate a restore in a test topology.

Confirm which hierarchy and policy your agency must align with, and which control catalog your assessors use. For federal systems, NIST SP 800-53 Rev. 5 is the current catalog, and the relevant PKI requirements sit in the cryptographic key and communications protection families, which your assessor will map to your own policies and logs. DeployOpen prepares systems, controls and evidence for assessments, but independent assessors and certification bodies issue the findings. Ask the implementer to produce a control mapping, issuance and revocation procedures, key custody records and inventory exports. Confirm with your assessor which artifacts they accept before the design is frozen.

A PKI touches almost every service, so the change plan matters as much as the design. Plan the migration so that existing certificates stay valid while new issuance moves to the new CA, and schedule each platform cutover in its own change window with a rollback path. Agree on a trust distribution plan for root and intermediate certificates on endpoints, servers and applications, because missed trust stores cause outages. Define who approves emergency revocations and how expiry alerts reach system owners. Ask the bidder how these steps appear in its fixed-scope plan and which of them the agency must staff.