Private PKI RFP questions

A root key ceremony should have named participants for each role, and the roles should be separate from one another. Typically this includes a ceremony administrator who runs the script, key custodians who hold the activation material, one or more witnesses from security or audit who are not operators, and a recorder who writes the log. Ask each bidder to list the roles, state which people may hold more than one role, and explain how the witness is kept independent of the operators. Confirm whether the witnesses must sign the ceremony record and whether an internal audit or compliance representative must be present for the event.

Yes, in most designs the root CA stays offline and signs only intermediate certificates during ceremonies, which keeps its private key away from any network. The root is brought up only when a new issuing CA is needed, when the root must be renewed or when a revocation must be published. Ask the bidder how the offline machine is built, where its key material is stored between ceremonies, how it is physically secured, and how signed artifacts move to the online systems, for example through removable media with checksums. Also ask what the bidder does if the root must be brought online during an incident.

A common pattern is an offline root CA that signs one or more online issuing CAs, and the issuing CAs sign end-entity certificates for services, devices and users. Separate issuing CAs can match trust zones, such as internal services, machine identity and staff devices, so that a compromise or a policy change in one does not affect the others. Ask the bidder to draw the hierarchy, state the path length constraints and name the certificate policy each CA enforces. Ask which platform will host each CA, for example step-ca, OpenBao PKI or FreeIPA Dogtag, and how trust is distributed to clients.

Key custodians should be chosen by role and clearance, not by convenience, and no single person should be able to activate the root key alone. A dual control model requires a threshold of custodians, such as an M-of-N split of key shares or smart card holders, to be present together. Ask the bidder who selects custodians, how their identity is verified before the ceremony, how their share is stored, how replacements are onboarded when someone leaves, and how rotation of custodians is recorded. Ask whether the custodian list is reviewed on a schedule and who approves changes.

A ceremony should produce a written, approved script that lists every step, the expected output of each command and the checks performed. It should also produce a signed log with timestamps, the names of attendees, the hardware and software versions used, the hashes of the artifacts created, and the storage location of each key share. Ask the bidder to show a sample script and log template, explain how the logs are sealed and retained, and state who can access them later. Confirm with your auditors which format they expect before the first ceremony, because the evidence is what assessors review.

The root lifetime is a policy decision that should be written into the certificate policy before the root is generated. Longer root lifetimes reduce the number of ceremonies but increase the period a single key must be protected and the difficulty of replacing it when algorithms change. Ask the bidder to propose a root lifetime, a plan for issuing a replacement root before the old one expires, and how the overlap period is handled so that existing services keep trusting certificates during the transition. Ask also how the bidder plans to retire intermediates and how long each issuing CA is expected to remain in service.

A credible bidder should deliver a ceremony plan before any key is generated, including a rehearsal on non-production hardware. The plan should cover equipment checks, environment setup, the approval chain, contingency steps if a custodian is unavailable, and the rollback path if a step fails. Ask whether the bidder runs a rehearsal, who trains the custodians and whether that training is repeated for new custodians. Confirm which parts of the plan are delivered as fixed scope and which become recurring work when the root is renewed or a new issuing CA is added.

An in-house team can run a ceremony if it has trained custodians, a tested script, an offline environment and independent witnesses, but the first ceremony is usually the hardest because the design decisions are made then. Ask yourself whether your organization has staff who can document and rehearse each step and whether the audit function can review the evidence. DeployOpen plans, documents and hardens self-hosted platforms in the client's own environment, and the scope of any PKI engagement is agreed in writing before work starts, so ask for the written scope, deliverables and timeline before deciding on an internal or partner-led ceremony.

Yes. step-ca is Smallstep's open-source online certificate authority for automated issuance and renewal of private X.509 and SSH certificates, and it supports ACME for automated renewal. Clients that speak ACME, such as common ACME agents and Kubernetes cert-manager, can request and renew certificates without manual steps. Confirm the exact ACME client support you need with the client vendors and test renewal against your own load balancers and appliances before you commit. The step-ca license is Apache-2.0, and the license file is in the smallstep/certificates repository. Ask your implementation partner to show a renewal run for each platform class in your inventory, not only a successful issuance from a test host.

The answer depends on what each platform can run, so ask for a coverage matrix with one row per platform. A typical matrix for a private PKI project lists the following:

• Web servers and reverse proxies: ACME agent or step client on the host, with a reload hook.
• Kubernetes ingress and internal services: cert-manager with an ACME or CA issuer, and trust bundles mounted into pods.
• mTLS service workloads: short-lived certificates from a provisioner, renewed by a sidecar or agent.
• Network devices: often vendor-specific enrollment, so confirm whether SCEP, EST or an API is supported before you assume automation.
• Windows and Linux endpoints: FreeIPA certmonger for enrolled Linux hosts, and Windows auto-enrollment only where your domain design supports it.

For each row, record the renewal method, the owner and the failure alert. Gaps in this matrix are where expired certificates usually come from.

Devices that cannot run an agent usually enroll through a protocol the device already speaks, or through an API called by a management system. SCEP-style enrollment is common for network gear and mobile devices, while some platforms call a REST API from a provisioning script. Confirm with each device vendor which protocol it supports, which certificate profile it accepts and how it stores the private key. Also confirm whether the enrollment endpoint sits on a network that the device can reach during provisioning. The first sentence of your RFP answer should name the protocol per device model, not a general claim about IoT or appliance support. Ask for the enrollment test results on the hardware you actually run.

In step-ca, provisioners define how a requester proves identity before the CA signs a certificate. The supported provisioner types include ACME, OIDC, cloud instance identity and JWK, and each one can carry its own policy on names, lifetimes and allowed key usages. A request authorized through OIDC is tied to a person or group in your identity provider, while a cloud instance identity provisioner ties the request to a virtual machine. In OpenBao, the equivalent control is the auth method plus the PKI role that defines allowed domains and TTLs. Ask the partner to document each provisioner or role, who owns it, how it is audited and how a provisioner is revoked when a team changes.

Costs come from three groups: the software licenses (step-ca and OpenBao are open source, so the license cost is zero for the core product), the infrastructure to run the CA and key protection, and the labor to integrate each platform. The integration labor is the largest and most variable item, because every platform needs its own renewal hook, test and runbook. Your internal team may pay for ongoing renewals, monitoring and certificate lifecycle operations, while an implementation partner is paid for the written scope. DeployOpen implements, integrates and documents self-hosted platforms in your environment under fixed scope agreed in writing. Ask any bidder to price each row of the coverage matrix separately so you can see what automation costs per platform.

A failed renewal is only a risk if nobody sees it before expiry. Ask how each path reports failure: ACME client logs, cert-manager status conditions, step-ca audit logs, and an independent expiry monitor that scans the endpoints themselves. The monitor should not depend on the same CA or automation path it is checking. Ask the partner to show the alert chain for one forced failure, including who receives it and how long it takes to reach a person. Also confirm the fallback when the CA is unreachable during renewal, since short lifetimes leave less time to recover. Your RFP should require a written runbook for each platform class.

Many teams can run renewal automation after handover if the platform classes are few and the runbooks are complete. The skills needed are ACME client configuration, Kubernetes and cert-manager administration, and enough understanding of your provisioners to change policy safely. The harder part is keeping the coverage matrix current as new platforms arrive. Ask the bidder which parts they hand over, what training is included, and whether support or upgrades are offered as a retainer. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and it documents the systems it builds so your team can operate them. Ask for a handover checklist that names each renewal path, its owner and its test cadence.

A sound proposal sets a separate lifetime for each certificate type, based on how the certificate is renewed and what happens if it expires. Ask the bidder to show a table with one row per type and columns for maximum lifetime, renewal trigger, renewal method and owner. Typical patterns are short-lived workload and mTLS certificates renewed automatically, shorter-lived SSH user certificates issued at login, and longer device certificates where the device may have limited connectivity. The proposal should name the exact values it recommends and explain why, rather than a single default applied everywhere.

Shorter lifetimes reduce the window of exposure for a stolen key, but every renewal depends on the CA being reachable. If the CA or its issuing path fails, certificates that renew often expire sooner in the outage timeline. Ask how the proposal sizes that risk: how long renewals can be deferred, whether issuing CAs run in more than one place, how the CA is backed up and restored, and what the runbook says when renewal fails. Ask for the expected behavior during a CA outage, tested rather than described.

Short lifetimes only work when renewal is automated for every certificate that uses them. Ask the bidder to list each platform and certificate type, the protocol used (for example ACME in step-ca, cert-manager issuers, or OpenBao PKI API calls), and the systems that still need manual renewal. Each manual item becomes a fixed expiry risk with an owner. Ask for the coverage percentage the bidder can document from your inventory, and for the list of exceptions with a compensating control for each one.

The policy should live in the CA configuration, not only in a document. In step-ca, lifetime limits and allowed names are set per provisioner. In OpenBao PKI, they are set on roles. In FreeIPA, certificate profiles govern issuance. Ask the proposal to map each certificate type to its profile, show the configuration keys or role settings that enforce the maximum, and state who may change them and how changes are approved. Ask for a test showing that a request exceeding the limit is refused.

Assessors look for a written certificate policy or practice statement, a record of how it is enforced, and evidence that it is followed. Ask the bidder to produce a lifetime standard that names each certificate type, its maximum lifetime, renewal method, exception process and review cycle. Ask how issuance logs and inventory exports will show compliance with that standard over time. DeployOpen prepares these controls and evidence for assessment, but auditors and certification bodies issue the findings, so confirm with your auditor which format they expect.

Review should happen on a fixed schedule and after any change to the platform, the certificate types or the regulations that apply. Ask the proposal to define the review cadence, the people who sign off, and the data they check, such as expiry reports, renewal failure counts and exception registers. Ask how a lifetime change is rolled out to existing certificates, and whether the plan covers certificates that cannot be renewed automatically. Confirm the cadence against your own internal policy and any framework you are assessed against.

Effort depends mostly on how many platforms need automated renewal, how many certificate types exist, and how much of the current estate is undocumented. Ask the partner for an itemized estimate covering inventory discovery, automation per platform, CA configuration of profiles and provisioners, monitoring of expiry, and runbooks for renewal failure. Ask which items are one-time and which recur, such as reviews, upgrades and certificate monitoring retainers. Any figure in the quote should trace back to the written scope, and you should ask what changes the price.

Your team can run it if the handover covers the operations that keep renewals working. Ask the partner what runbooks, configuration exports, monitoring dashboards and training are included, and how the CA backup and restore process is tested. Confirm who holds the keys to change profiles and who approves changes. Ask whether ongoing support, upgrades and continuous testing are offered as a retainer, and what that covers for your staff who will own the system day to day.