How to use this private PKI requirements checklist
This checklist sets out what a private certificate authority must do before you choose a platform. It covers hierarchy and key storage, issuance protocols such as ACME and API enrollment, certificate profiles and lifetimes, revocation, high availability, inventory and expiry monitoring, and audit logging. Use it to compare step-ca, OpenBao PKI, FreeIPA and cert-manager against the same list, so each product is judged on the same requirements rather than on feature lists alone. Cert-manager is a Kubernetes controller that issues from an existing issuer, so it is compared as a client of a CA rather than as a CA itself.
Requirements are grouped by function, security, integration, operations and compliance. Each one carries a verification step, which is the test you run in a proof of concept or ask a vendor or partner to demonstrate, such as revoking a test certificate and confirming that clients reject it, or forcing a standby node to take over and checking that issuance resumes. Record the result next to each requirement. A requirement without a verification step is a claim, and claims are where PKI projects usually fail.
The checklist does not replace a design review of your own environment. Your certificate volumes, device estate, trust relationships with partners, regulators and existing government or bank PKI hierarchies, and key custody rules will decide which items are mandatory and which are optional. Treat each item as a question to answer for your organization, and bring the answers to the design review, where an implementation partner can test them against your systems. Confirm every product version and license term with the vendor before you rely on them.
Functional requirements every private CA must meet
This table lists the functional requirements a private certificate authority must meet, why each matters, and a concrete test to confirm it on a candidate platform. Use it as a checklist during evaluation and again during acceptance testing. Each row names the evidence to collect, so the result can be shown to an assessor later.
| Requirement | Why it matters | How to verify |
|---|---|---|
| Offline root with online issuing CAs | Keeps the root key off the network so a compromise of issuing infrastructure does not force re-trust of the whole hierarchy | Confirm the root is signed in a documented key ceremony, then issue a test leaf from each issuing CA and validate the chain to the root offline |
| Key storage for each CA (software, HSM, cloud KMS or YubiKey) | Determines who can extract CA keys and how audits of key custody are answered | Record where each CA private key lives, confirm the platform supports that option, and test that a key cannot be exported in plain text |
| ACME issuance | Supports automated renewal for servers and containers without manual requests | Run an ACME client against the CA with a test domain, then confirm the issued certificate, renewal and revocation behavior |
| Enrollment for devices and managed endpoints (SCEP-style or equivalent) | Many network devices and MDM-managed endpoints cannot speak ACME and need a separate enrollment path | Enroll a test device through the chosen protocol, confirm the certificate chain installs, and check the request is authorized by the intended identity |
| REST or API issuance and revocation | Lets internal applications and pipelines request certificates under policy without a human in the loop | Call the API with a scoped credential, issue and revoke a test certificate, and confirm the action appears in audit logs |
| Certificate profiles per use case (server TLS, mutual TLS, client, document signing) | Each use needs different extended key usage, key usage and trust settings, and mixing them creates misuse risk | Issue one test certificate per profile and inspect the extensions, then attempt to use each certificate for a purpose it should not serve |
| Configurable lifetimes per profile and per CA | Shorter lifetimes reduce exposure if a key leaks, but only if renewal runs reliably | Set a short and a longer lifetime, confirm each is enforced at issuance, and verify automated renewal fires before expiry in a staging environment |
| SAN and key-type policy | Stops requests for names or key algorithms outside the approved domains and standards | Submit requests with an out-of-scope name and an unapproved key type, and confirm both are rejected and logged |
| Revocation and status publication | Compromised or decommissioned certificates must stop being trusted, and clients must be able to check that status | Revoke a test certificate, then confirm the CRL or status responder reflects it and that a client rejects it within your defined window |
Which issuance protocol fits which workload
ACME is the protocol to start with for web servers, load balancers and ingress controllers that need certificates renewed without human steps. The requester proves control of the name being issued, usually by answering an ACME challenge that the CA validates, so the CA must be able to reach the host or the DNS records involved. In Kubernetes, cert-manager acts as the ACME client and can also request certificates from a CA issuer, so the platform team sets the issuer policy once and application owners do not handle keys. step-ca supports ACME for automated renewal, and its ACME provisioner is the configuration to review first.
- Proof of control: The requester proves it controls the DNS name or host through an HTTP-01 or DNS-01 style challenge, which the vendor documentation must confirm for your setup.
- Approval: Approval is set in policy, not per request. Name constraints and allowed domains are approved once by the security team and then enforced automatically.
- Ingress and workloads: cert-manager issuers in Kubernetes renew certificates before expiry and store them in Kubernetes Secrets, so access to those Secrets becomes part of the review.
- Internal names: Private names that public validation cannot reach need a different challenge or a CA issuer, so confirm which names will use which path.
- Confirm with the vendor: Confirm the challenge types each ACME provisioner supports and how it handles wildcard names.
Before approving ACME, check that every name in scope can be validated by the chosen challenge inside your network.
Application services, build pipelines and internal automation usually cannot answer a web challenge, so they request certificates through an API or a provisioner that authenticates the caller. step-ca provisioners include OIDC, cloud instance identity, JWK and ACME, and each one defines what the requester must prove. An OIDC provisioner ties issuance to a workforce or workload identity from your identity provider, while a JWK provisioner relies on a key pair the operator registered in advance. Approval is usually built into the provisioner's claims and templates instead of a person reviewing each request.
- Proof of identity: The requester presents a token or key that the provisioner accepts, so the identity provider's claims define who can request which names.
- Approval: The security team approves the provisioner configuration, the allowed names and the maximum lifetime. Pipelines should never hold a long-lived signing key.
- Lifetime: Set short certificate lifetimes for service identities so renewal is routine and compromise windows stay small.
- OpenBao: OpenBao's TLS certificate auth method lets a service authenticate with a client certificate, which is useful when the caller already holds a trusted identity.
- Confirm with the vendor: Confirm how the chosen provisioner handles token expiry, claim mapping and revocation of a registered key.
For each pipeline, write down who may approve its provisioner and what happens when its credentials are rotated.
Laptops, phones and network devices such as routers and firewalls often request certificates through SCEP-style enrollment, because many device management and network products already speak that protocol. The device proves its identity with a challenge password, a pre-installed certificate or a link to a device record in management tooling, and the approval point is usually the device management system rather than a person. SCEP support is not part of the step-ca facts supplied for this page, so the reader must confirm whether the chosen CA, or a companion component, provides it before assuming a design.
- Proof of identity: Confirm whether enrollment relies on a shared challenge secret, a device identity certificate or a management server attestation, since each has different risks.
- Approval: Assign approval to the device management owner, and require that revoked or retired devices cannot re-enroll.
- Scope: Limit which certificate profiles each device class may request, such as Wi-Fi client or VPN, so a laptop cannot obtain a server profile.
- Revocation: Confirm how a lost device's certificate is revoked and how quickly revocation is published to relying systems.
- Confirm with the vendor: Ask for written confirmation of SCEP support, supported challenge methods and whether enrollment logs flow into your audit trail.
If SCEP is not supported by the chosen CA, plan the enrollment path before the device fleet is chosen.
Virtual machines in cloud accounts can prove their identity using the metadata and signed identity documents the cloud platform issues to them, which avoids placing a static secret on each host. step-ca's cloud instance identity provisioner is designed for this pattern, so the CA can trust a request only when the instance's cloud identity matches an allowed account, region or instance attribute. This path suits fleets that are created and destroyed automatically, because the certificate follows the instance rather than a copied key.
- Proof of identity: The instance proves it is a specific cloud resource by presenting the identity document the platform signs, which the provisioner verifies.
- Approval: The cloud account owner and the security team agree on which accounts, images and tags may obtain certificates.
- Trust boundary: Anyone who can launch instances in the allowed account can obtain certificates, so account governance becomes part of PKI governance.
- Lifetimes: Pair this path with short lifetimes and automatic renewal, since instances may be terminated without notice.
- Confirm with the vendor: Confirm which cloud platforms and identity documents the provisioner supports and how it handles instances that are cloned from a template.
Before enabling this path, document which cloud accounts and images are allowed to request certificates and who may change that list.
Hosts on isolated networks cannot use public validation or cloud identity documents, so their issuance path depends on what the internal network can prove. Many teams use an API or provisioner that trusts an internal identity source, or a TLS client certificate issued from a trusted intermediate, with the CA reachable only from inside the enclave. This is where the design differs most from the cloud path, because every request must be authenticated against something under your control.
- Proof of identity: The host proves identity with a certificate issued by the internal chain, or with a token from an internal identity provider.
- Approval: Restrict approval to named operators, and record who approved each provisioner change.
- Reachability: Confirm that renewal works without internet access, including revocation list or OCSP distribution inside the enclave.
- Key custody: Confirm where CA keys are stored, such as an HSM, cloud KMS or hardware key, as step-ca documents those options for its keys.
- Confirm with the vendor: Ask how renewal behaves during a CA outage and which components must run inside the enclave.
After selecting paths, test renewal on an isolated host to confirm the chain, trust store and revocation checks work end to end.
How lifetimes and revocation rules shape the design
Short certificate lifetimes make automated renewal a design requirement, not a convenience. When a certificate lives for months, a manual renewal ticket might be survivable. When it lives for days or hours, every service, gateway and device needs an automated path to request, install and reload its certificate without an engineer involved. Before you pick a CA, list every certificate consumer and confirm it supports ACME, an API call or an agent that can renew it unattended. Consumers that cannot do this are the ones that will cause outages, so flag them early and decide whether they are replaced, wrapped in a renewal agent or given a longer lifetime with a documented exception. Public TLS lifetimes are falling on a published schedule (200 days from March 2026, 100 days in 2027 and 47 days in 2029), which is useful context for your own planning, but your internal lifetime policy is yours to set. Confirm it with your assessor before you configure the issuing profiles.
Revocation matters less as lifetimes shrink, but it still matters for compromised keys and devices. A certificate that expires in a day limits the damage from a stolen key, yet a compromised device or a leaked private key remains trusted until it expires, so you still need to revoke quickly. Decide which revocation mechanism each consumer uses: CRL distribution points, OCSP responders, or both, and where those endpoints sit inside your network. Check that the CRL or OCSP service is reachable from every segment that validates certificates, and that the CRL publication interval is short enough for your incident response targets. Document what happens when a client cannot reach a revocation endpoint: many clients fail open and accept the certificate, and some fail closed and break the service. Test that behavior for each product in your estate, because the answer determines whether an outage of the revocation service is a security exposure, an availability incident or both.
Security requirements for CA keys and operators
A private CA is only as trustworthy as the keys it signs with and the people who can use them. The cards below set out the controls a CA design should meet before any certificate is issued, and what to check in the chosen platform and environment.
Offline root key custody
The root CA key should never sit on a network-reachable host. Keep it offline, generate it in a documented key ceremony, and sign only subordinate issuing CA certificates from it. Plan for the root's lifetime and for the procedure to rotate or replace it years ahead of expiry. Verify that the root key is generated and stored outside any server that runs the online issuing service, and that the ceremony produces records an assessor can review.
HSM or cloud KMS for issuing keys
Online issuing CA keys need protection that prevents copying the private key out of the device or service. Hardware security modules, cloud key management services and hardware tokens are the usual options. step-ca can protect CA keys in HSMs, cloud KMS or YubiKeys, and OpenBao manages keys under its own controls. Confirm which protection mechanism each platform supports, and whether the signing operation is performed inside the boundary of that device.
Separation of CA duties
Policy ownership, certificate issuance and audit review should belong to different people or groups, so no single operator can change the rules, issue a certificate and then cover the trail. Define who approves certificate profiles, who runs issuance and who reviews logs. Check that the platform's roles and approval workflow can enforce this split, rather than relying on shared administrator accounts.
Administrator authentication through the identity provider
Every person who can administer the CA, approve a key operation or unlock an HSM should authenticate with a unique identity and multi-factor authentication. The HIPAA Security Rule requires unique user identification and person or entity authentication, and the FTC Safeguards Rule requires multi-factor authentication for any individual accessing an information system. Confirm that administrator logins go through the central identity provider and that shared or local accounts are disabled.
Encryption of key material at rest
CA private keys, the storage backend holding them and any backups must be encrypted so that a copy of the data alone does not expose signing capability. OpenBao encrypts secrets before they are written to storage, and its supported storage backends should be reviewed for their own encryption and backup handling. Verify where encryption keys are held and who can unseal or recover the system, and confirm that backups inherit the same protection.
Protection of the signing path
Unauthorized issuance usually comes from a misconfigured provisioner, a stolen automation credential or an overly broad issuing policy, not from breaking the key itself. Restrict which identities can request which names and lifetimes, require approval for high-risk profiles, and alert on unexpected issuance. Test that a request outside the approved names or lifetimes is refused and generates a log entry.
High availability and expiry monitoring for issuing CAs
A CA outage stops renewals, so the issuing path needs redundancy that you can test, not just a second server on paper. If you run OpenBao PKI as the issuing CA, the documented high availability model uses one active node that holds a lock in the data store, with standby nodes that forward or redirect requests. The officially supported HA backends are integrated storage (Raft) and PostgreSQL. Confirm with your platform team which backend you will operate, and run a failover drill: stop the active node during a test window, confirm a standby takes over, and verify that a test certificate can still be issued through the same endpoint your automation uses.
Read scaling is a different capability from issuance availability. Since OpenBao 2.5.0, Raft standbys can serve read-only operations, and v2.7.0 extended this to PostgreSQL. Those reads help with horizontal scale for lookups and status calls, but they do not guarantee that a signing request succeeds during a failover. Ask your implementation partner to show which operations a standby serves, and test issuance and revocation separately from reads. Also confirm how your step-ca or cert-manager issuers reconnect after a failover, since a client pinned to one address can stall renewals even when the cluster is healthy.
Expiry monitoring only works if the inventory is complete. Record, for every certificate, its owner, issuing CA, lifetime, and renewal method (ACME, API, manual, or cert-manager). Certificates without an automated renewal method need a named owner and a calendar reminder, and those are the ones most likely to expire unnoticed. Set alert thresholds well before the deadline, route alerts to the owner rather than a shared mailbox, and escalate when an alert goes unacknowledged. Treat an alert on the CA's own intermediate or issuing certificate as the highest priority, because its expiry breaks every certificate beneath it.
Operational requirements and how to verify them
This table lists the operational requirements a private CA must meet after launch, what good looks like for each, and a drill that proves it works. Read it as a test plan: a requirement is only met when your team has restored, revoked or recovered something in a rehearsal. The main takeaway is that a backup, runbook or key ceremony record you have never used is a hypothesis, not a control.
| Requirement | What good looks like | How to verify |
|---|---|---|
| Backup and restore of CA keys and configuration | Encrypted backups of CA keys (or key material held in an HSM or cloud KMS), issuer configuration, provisioner settings and policy files, stored apart from the CA hosts with restricted access and logged retrieval | Restore the CA into an isolated environment from backup, then issue and validate a test certificate chain against the restored CA |
| Upgrade cadence and support policy | A documented upgrade schedule for the CA, its storage backend and automation components, with a rule for when a security fix forces an out-of-cycle release. Current release for reference: OpenBao v2.7.1 (October 1, 2026), and step-ca and cert-manager track their own releases | Confirm each vendor's support window for the version you run, then upgrade a staging copy and verify issuance, renewal and revocation still work before production |
| Emergency revocation runbook | A written procedure naming who can trigger revocation, how a compromised certificate or issuing CA is identified, how revocation is published to relying systems, and how replacement certificates are issued | Run a timed tabletop with a simulated key compromise: revoke a certificate, confirm the revocation status is visible to a test client, and reissue a replacement |
| Key ceremony documentation | Scripted ceremony steps for root and intermediate key generation, witnesses named, custody of activation material split across people, and signed records stored with the CA inventory | Ask for the most recent ceremony record and check it against the script. Rehearse a ceremony for a non-production hierarchy with the same people and tools |
| Monitoring of issuance errors | Alerts on failed ACME, API or enrollment requests, rejected CSRs, provisioner authorization failures and automation job errors, routed to an owner who responds | Trigger a controlled failure (for example, an invalid challenge or an unauthorized provisioner) and confirm the alert fires and reaches the on-call queue |
| Capacity planning | A forecast of certificate volume by source (ingress, service mTLS, devices, SSH), with headroom for renewal peaks and a documented storage growth rate for the CA database | Load test issuance and renewal at the forecast peak in staging, and confirm the backend and CA stay within agreed response times |
| Disaster recovery exercise | A documented recovery target for the CA and its dependencies, a failover path for the issuing CA and its datastore, and a plan for what happens to renewals while the CA is down | Run a scheduled failover drill that takes a node or the primary datastore offline, then measure the time to restore issuance and record gaps for remediation |
| Expiry and inventory checks | A certificate inventory fed from the CA and scanners, with expiry alerts that reach the owning team before renewal windows close | Pick ten certificates at random, confirm each appears in the inventory with an owner, and verify the expiry alert fires in a test window |
What audit logging must capture for assessors
What events must a private CA log for an assessor to trust it?
A private CA should log every issuance, renewal failure, revocation, policy or profile change, key use and administrator login, each with a timestamp, the acting identity and the outcome. Assessors look for a complete activity record rather than a sample. The HIPAA Security Rule at 45 CFR 164.312 requires audit controls that record and examine activity in systems containing ePHI, and the FTC Safeguards Rule at 16 CFR 314.4 requires covered financial institutions to monitor and log the activity of authorized users. Both obligations apply to activity records generally, so the CA's logs should cover the events that show who could obtain trusted certificates and when. Confirm with your counsel or assessor which of these rules apply to your environment.
How do you protect CA audit logs from being changed?
Logs should be written to a store that the CA operators cannot edit, with access separated from the people who run issuance. Common controls include append-only or write-once storage, cryptographic chaining or signing of log batches, restricted delete rights, and forwarding copies to a central system outside the CA host. Record who can read and who can administer the log store, and test that tampering would be detected. The exact control set depends on your assessor and your existing logging architecture, so ask them which evidence of integrity they expect before you design the store.
How long should private PKI audit logs be kept?
Retention is set by your own policy and by the rules that apply to your sector, not by the CA software. Neither the HIPAA Security Rule nor the FTC Safeguards Rule text supplied here sets a specific number of years for these records, so do not assume one. Decide a retention period that covers your longest certificate lifetime plus the period in which a dispute about an issued certificate could arise, and align it with your records policy. Confirm the exact requirement with counsel or the assessor, and document the chosen period in the logging standard.
Who should review private CA logs, and how often?
Review should be done by someone who does not operate the CA, such as a security operations analyst or a compliance reviewer, on a schedule written into your policy. Alerts on high-risk events like unexpected root or intermediate activity, policy changes, or repeated failed administrator logins should be reviewed as they occur. Periodic reviews of issuance volume against the certificate inventory catch unexpected certificates. The HIPAA and FTC provisions cited above require monitoring and examining activity, not a specific cadence, so your assessor will expect the cadence to match your risk assessment. Record each review with its date, reviewer and findings.
How do CA logs reach a SIEM such as Wazuh?
Logs typically reach a SIEM by forwarding from the CA host or the CA service to a collector that ships them to the central platform. Wazuh is an open source security platform with SIEM capabilities, so it can serve as that central point, but you must confirm which log formats step-ca, OpenBao or FreeIPA Dogtag emit and which decoders or custom rules you need. Use encrypted transport, synchronized clocks, and a defined field set so that issuance and admin events can be correlated. Test that a simulated event produces an alert end to end before the assessment, and document the pipeline as evidence.
Can our own team run the audit logging, or do we need a partner?
Your team can run the logging if it has people who understand both the CA and the SIEM, and the work is largely configuration, retention, review and evidence collection. A partner is useful when the logging pipeline must be built, integrated with the CA and SIEM, hardened and documented for an assessment. DeployOpen implements, integrates and documents self-hosted open-source platforms inside the client's own infrastructure and prepares evidence for compliance assessments, but it does not issue audit reports or certifications. Scope, deliverables and timelines would be agreed in writing before work starts, and a quote follows from that written scope.
How DeployOpen scopes and delivers a private PKI implementation
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a private PKI, that means turning this checklist into a written scope for your hierarchy, issuance paths, lifetimes and audit trail, then building and handing over the CA with the evidence your assessors will ask for.
How we scope
- Map your certificate populations, including web, mutual TLS, Kubernetes, SSH and device certificates, before choosing an issuing CA.
- Record the hierarchy, key storage model and HSM or KMS requirements in a written scope agreed before work starts.
- Confirm which issuance protocols, certificate profiles and lifetimes each platform owner needs, with named acceptance criteria.
How we build
- Deploy the chosen CA components, such as step-ca, OpenBao PKI or FreeIPA, inside your environment with high availability designed in.
- Configure certificate profiles, provisioners or auth methods and automated renewal for each in-scope platform, then test revocation and expiry handling.
- Enable audit logging for issuance, revocation and administrative actions, and verify that records reach your existing log store.
How we hand over
- Deliver runbooks for key ceremonies, CA recovery, backup restoration and certificate issuance so your staff can operate the CA.
- Provide configuration documentation and a certificate inventory with expiry monitoring mapped to your written control requirements.
- Walk your operations and security teams through the handover and record which open items remain with your owners.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the initial handover, scoped in writing.
- Plan and test CA and component upgrades, including patching and renewal of intermediate certificates, on a schedule you approve.
- Prepare the systems, controls and evidence your independent auditors or certification bodies will review, without issuing any attestation ourselves.
