OpenBao PKI and certificate authority setup guide

How to set up an OpenBao PKI certificate authority in your own infrastructure

Teams that need internal TLS certificates for services, workloads or devices can run the certificate authority on infrastructure they control by using the OpenBao PKI secrets engine, which can act as both a root and an intermediate CA. It issues certificates through named roles, supports short-lived certificates and provides revocation. This section covers the design and setup of that CA, not the wider secrets rollout or the onboarding of clients, which are described in other sections of this page. Teams usually need this when manual certificate handling no longer scales, when they want certificate lifetimes short enough that revocation matters less, or when issuing authority must be separated by environment, such as production, staging and development. Enabling a PKI mount takes minutes. Designing the CA takes longer because four decisions shape everything after it: how the root key is held and who can use it, how names and trust anchors are distributed to clients, what each issuing role is allowed to sign, and how revocation behaves when a certificate or key is compromised. Start with the root. In most designs the root CA is generated or imported once, kept offline or in tightly restricted use, and used only to sign one or more intermediate CAs that OpenBao then runs. Decide where the root key lives, who must be present to sign an intermediate, and how that process is recorded. Write down the hierarchy, including the intermediate for each environment, before you enable any issuing role. Changing a root later means re-distributing trust to every client, which is the most expensive mistake to undo. Next, define naming and issuance policy. Each PKI role sets the allowed domains, whether subdomains and wildcards are permitted, maximum TTL, key type and size, and whether clients may request arbitrary common names. Build roles per purpose, for example one for internal web services and one for workload identities, rather than one broad role. Then confirm the revocation path: check how certificate revocation lists and the OCSP responder are exposed, how long clients may cache them, and which systems will actually check them. Confirm these behaviors with your own PKI policy and the current OpenBao PKI documentation before you rely on them in production.

Which OpenBao components a certificate authority depends on

An OpenBao certificate authority is a set of connected parts rather than one engine. Issuance depends on the PKI mount, the CA material it holds, the roles that constrain what gets signed, the authentication that decides who may request certificates, and the storage and unseal state beneath all of it.

PKI secrets engine mount and lease settings

The PKI secrets engine is mounted at a path, and that mount carries the maximum lease settings that cap how long issued certificates and their leases can live. These limits set the upper bound for every role on the mount, so a too-generous maximum cannot be fixed later by a narrower role alone. Confirm the exact tuning parameter names and their defaults against your OpenBao version before you set them.

Root and intermediate CA material

The CA private key and certificate live inside the PKI mount, and the root and intermediate hierarchy determines what can be revoked and where trust ends. Decide whether the root stays offline in a separate mount, and plan how intermediate certificates are generated, signed and imported. Losing this material or its key custody breaks every certificate the CA has issued.

PKI roles for names and key types

PKI roles define which common names, subject alternative names, domains and key types a certificate request may use, along with its maximum TTL. A role is the main control over what a holder of the issuing permission can obtain, so overly broad roles let any authorized caller request names outside its remit. Review each role against the domains and key algorithms your services actually need.

Issuing, signing and revocation endpoints

Clients use the issue and sign endpoints to obtain certificates, and the revoke and tidy operations to retire them and clean stored entries. Applications, automation and security tooling all depend on these paths, so any change to the mount path or role name breaks them. Confirm the endpoint names and request fields in the OpenBao PKI documentation for your release.

Certificate URLs embedded in issued certificates

Issued certificates can carry CRL distribution point and OCSP or issuing certificate URLs, which relying systems use to check revocation and chain status. These URLs are set in the CA configuration and must resolve from every network where the certificates are validated. Changing them after issuance does not update certificates already in circulation, so set them before the first production issuance.

Authentication methods and policies for signers

Issuers and clients authenticate with methods such as TLS certificate, AppRole and Kubernetes auth, and the policies attached to those identities control who may call the signing paths. Map each workload to the narrowest policy that allows its role, and review it when a service changes. Confirm which auth methods your OpenBao version enables and their configuration parameters before rollout.

Storage backend and unseal state

All CA material is stored through the configured storage backend, and the cluster must be unsealed before any PKI operation succeeds. A sealed node, a failed storage backend or a lost unseal method stops issuance and revocation even when the mount and roles are intact. Plan the storage backend, high availability and unseal custody together, since they set how often the CA can be unavailable.

Which CA design decisions shape operations later

This table compares the CA design decisions that are hardest to change once certificates are issued. Read each row for the operational cost it adds in key custody, renewal load and trust distribution, and for the conditions where that option fits. The main takeaway is that root key handling and revocation publishing matter more over time than the initial mount layout.

Decision	Operational cost	When it fits
One root with one intermediate	Fewest moving parts. A compromise or forced rotation affects every workload on the single chain.	One team, one environment, a small estate
Per-environment or per-purpose intermediates	More mounts and signing steps to run. Limits blast radius and lets you retire one intermediate without reissuing everything.	Several environments or regulated workloads with separate owners
Root generated inside OpenBao	Root key custody follows OpenBao's unseal and storage controls. Confirm how any exported or backed-up root material is protected.	Teams that keep all PKI operations inside one platform
Root signed offline or imported material	Root key stays outside the cluster, adding signing ceremonies and custody procedures. Imported chains need careful validation.	Policy requires root keys outside the running platform
Online root or root offline after issuing the intermediate	An online root keeps the key exposed to the cluster. An offline root makes each intermediate renewal a planned manual signing step.	Online for small internal estates; offline where intermediate renewal is infrequent and scheduled
One PKI mount or several mounts or namespaces	One mount is simpler to audit but shares roles and policy. Separate mounts or namespaces add setup and duplicated policy, with stronger tenant isolation.	One mount for a single trust domain; separate mounts or namespaces for distinct owners
Short-lived certificates with automated renewal	Clients must renew automatically and renewal failures need monitoring. Revocation depends less on CRLs because exposure windows are short.	Workloads that can renew unattended, such as service-to-service traffic
Longer-lived certificates with manual rotation	Fewer issuance events, but rotation depends on people and tickets. Revocation and CRL distribution carry more of the risk.	Devices or legacy systems that cannot automate renewal
Revocation and CRL endpoint location	Every relying party must reach the published endpoints, including outside the core network. Publishing choices set trust distribution and outage exposure.	Confirm reachability and client caching behavior with each team before go-live

How to build the OpenBao PKI hierarchy step by step

This sequence takes an OpenBao PKI deployment from a written design to a verified internal certificate chain, with constrained issuing roles, least-privilege access and a tested revocation path. Each step ends with a check your team can run before moving on.

Document the hierarchy, names and lifetimes
The PKI owner and security architect record the root and intermediate tiers, the domains and internal names each tier may sign, the key types, and the lifetime of every certificate authority and leaf certificate. The record also names the hostnames that will serve issuing and CRL URLs and who may request certificates. This step produces an approved design document that every later step follows. It is done when each leaf lifetime is shorter than the intermediate that signs it, and each intermediate expires before the root. Confirm the root and intermediate lifetimes with your own policy owner before any key is generated.
Enable the PKI engines at dedicated paths
The platform engineer enables the PKI secrets engine twice, once for the root and once for the intermediate, using paths such as pki_root and pki_int so each tier has its own mount, policies and audit trail. Keeping the root on its own mount makes it easier to restrict and to remove from daily use later. The closing check is a listing of mounts in which both paths appear with the pki type, for example by running the secrets list command with the detailed flag. Record the mount paths in the design document so that policies in later steps reference the correct names.
Set the maximum lease TTL for each mount
The platform engineer tunes each PKI mount so its maximum lease TTL covers the longest certificate that mount will issue. The root mount needs a value covering the root lifetime, and the intermediate mount needs a value covering the intermediate lifetime from the design record. If the mount limit is shorter than a certificate lifetime, the certificate is capped and the design fails silently. The closing check is reading the tuning settings for each mount and comparing the returned maximum with the value recorded in step one. Do not move on until both values match or exceed the design.
Generate the root and set issuing and CRL URLs
The security engineer generates the root key inside OpenBao with an internal root generation call, or imports an existing root key if your key custody policy requires it. The engineer then writes the issuing certificate URL and the CRL distribution URL to the mount configuration, pointing at the hostnames recorded in step one. These URLs are embedded in every certificate the hierarchy issues, so changing them later means reissuing certificates. The closing check is reading back the URL configuration and inspecting the root certificate with openssl, confirming it is marked as a CA and carries the expected subject and validity dates.
Sign the intermediate CSR with the root
The security engineer generates the intermediate key and certificate signing request inside the intermediate mount, then sends that request to the root mount to be signed as an intermediate. The signed certificate is imported back into the intermediate mount so the intermediate can issue. The root key stays on the root mount and is used only for this signing operation. The closing check uses openssl to confirm that the intermediate names the root as its issuer and that the chain verifies with the root certificate as the trust anchor. If verification fails, stop and correct the import before creating any roles.
Configure issuing roles with constraints
The PKI owner creates one or more issuing roles on the intermediate mount. Each role sets the allowed domains, whether subdomains are permitted, the permitted key types and sizes, and the default and maximum certificate lifetimes. Separate roles per environment or per team keep a compromised client from requesting certificates for other systems. The closing check is a deliberate request for a name outside the allowed domains. The role must refuse it, and the refusal should appear in the test output. Repeat the check for a key type the role does not permit so the constraint is confirmed in both directions.
Write least-privilege policies and bind auth methods
The security engineer writes one policy per client group that allows only the issue operation on the specific role that group needs, and grants no read access to the root or the signing paths. Servers authenticate with AppRole, as OpenBao recommends for servers, while workloads on Kubernetes or clients that present certificates use the auth methods that fit their platform. Administrators receive separate policies for managing roles and never hold issue rights by default. The closing check is logging in as each client identity, attempting to issue from a different role, and confirming the request is denied. Confirm token lifetime settings with your team, since they are not set in this step.
Issue a test certificate and confirm the chain
The platform engineer issues a test certificate from one role using a client identity from step seven, then saves the leaf, the intermediate and the root to files. The engineer verifies the leaf against the root using openssl with the intermediate supplied as untrusted, and checks the subject alternative names and validity. The engineer then revokes the test serial through the intermediate mount and reads the CRL to confirm the serial is listed. This step closes the build: a passing chain verification and a CRL that lists the revoked serial show that issuance, trust and revocation all work before any production client is onboarded.

Why root key custody decides the whole CA design

The root signing key is the trust anchor of your internal certificate authority, so how you hold it decides how much of the rest of the design can be changed later. Every intermediate, issuing role and leaf certificate traces back to it. Before you enable the PKI secrets engine or run a root generation or signing command in OpenBao, agree with your security and compliance owners where the root will live, who can use it, and what happens to it after the intermediate is signed. Treat that decision as the first design choice, not a detail to settle during the build.

There are two broad options. The first keeps the root online inside OpenBao and uses it for routine signing of intermediates or, in some designs, leaf certificates. This is operationally simple: rotation of intermediates is a routine API call, and the team can respond to a compromised intermediate without a ceremony. The cost is exposure. Anyone or anything with a policy that can reach the root mount can sign under your trust anchor, and a compromise of the cluster or its unseal material puts the root itself at risk. Incident response then has to assume the root may be compromised, which usually means re-rooting the whole hierarchy.

The second option generates the root, signs the intermediate, and then takes the root out of service. Its private key is kept offline or otherwise sealed away from routine access, and OpenBao only holds the intermediate used for daily issuance. Incident response becomes narrower: if an intermediate is compromised, you revoke it and sign a replacement from the offline root. The trade-off is that every intermediate change needs a deliberate, slower process, and the team must be able to run that process reliably under pressure. Confirm with your own team whether that offline procedure is documented and practiced before you commit to it.

Re-rooting later is the hardest change in either model. Replacing a root means distributing a new trust anchor to every client, service, and device that validates your certificates, and planning how the old and new roots coexist during the transition. Ask the question directly: if the root must be replaced in three years, what would that take in your environment, and who would sign off? The answer shapes how long the root should live and how many intermediates you expect to rotate underneath it.

The custody of the OpenBao cluster itself belongs to the same trust chain. Whoever can unseal the cluster, or read the storage backend and its encryption material, can ultimately reach the keys the PKI engine protects, so cluster custody and root custody must be decided together. The mechanics of the unseal approach are covered in the security hardening topic, and the implementation plan covers how unseal is scoped and priced. Here, make sure the custody decision for the root explicitly names the people and systems that can reach the cluster, and record that answer before any signing command runs.

How the CA setup changes on single node, HA, Kubernetes and air-gapped deployments

A single-node deployment is the simplest layout to build and reason about. One OpenBao server hosts the PKI engines, serves issuance and revocation, and depends on one storage backend and one unseal path. That simplicity concentrates risk, so the design work moves toward recovery planning and change control.

Restarts interrupt the CA. While the server restarts, it cannot issue or revoke certificates. Schedule change windows and tell application owners when renewals may fail.
Unseal carries the full risk. Anyone who can unseal the server can operate the CA. Confirm how unseal material is split, stored and held.
Backup is the recovery plan. Storage backups and CA key material must restore to a target you have tested. Run a restore before go-live, not after an incident.
Revocation depends on the same node. Revocation requests and CRL publication are served by that one server, so a failure also affects certificate status checks. Confirm where published CRLs are cached and for how long clients rely on them.

Before you choose this model, confirm with your risk owners whether a single node meets the availability that your certificate consumers expect.

Which controls keep an internal CA trustworthy

An internal certificate authority is only as trustworthy as the controls around its root, intermediates, roles and records. The cards below cover the decisions that limit what a compromised token, role or intermediate can do, and the checks to run against your own OpenBao version before go-live.

Restrict who can sign and manage roles

Write policies so that only a small set of identities can sign intermediate certificates, create or modify PKI roles, and change CA configuration. Separate the identities that issue end-entity certificates from those that administer the mount, so a workload credential cannot widen its own issuing rights. Review the capabilities on each PKI path against the policy documentation for your OpenBao version before you grant them.

Limit domains and key types per role

Each PKI role should allow only the domains, subdomains and key types that its consumers need. Restrict wildcard issuance, disable unneeded options such as allowing any name, and set the maximum TTL per role rather than relying on the mount default. Test each role with a request that should fail, such as an out-of-scope domain, to confirm the constraint is enforced.

Keep the root offline or tightly scoped

Generate the root CA once, sign the intermediates, and then keep the root mount unused for routine work. Where the design allows, take the root out of the running cluster entirely and store its key under dual control. The root should exist to sign intermediates and little else, and every use of it should be a planned, recorded event.

Do not use the root token for routine issuance

The root token has unrestricted access to the cluster and should not be used for day-to-day certificate issuance, role changes or automation. Issue scoped tokens or use an approved auth method for each consumer, and revoke any root token generated during setup once its job is done. Document the break-glass procedure, who holds it and how it is logged.

Separate intermediates by environment

Issue a separate intermediate CA for each environment, such as production, staging and development, so that compromise or misconfiguration in one does not reach the others. Give each intermediate its own mount, roles and policies, and confirm that a certificate from one chain is not trusted by another environment's clients. Name the owner and expiry of each intermediate in your inventory.

Control who issues CA and signing certificates

Requests for intermediate or signing certificates are the most sensitive operations in the PKI. Restrict them to a named group, require a second approver through your change process, and keep them out of automation pipelines that also issue leaf certificates. Verify that the policy for these paths is narrower than the one used for ordinary issuance.

Protect CRL and issuing URLs

Clients rely on the CRL distribution point and the OCSP or issuing certificate URLs embedded in each certificate to check revocation and build chains. Set these URLs to addresses your clients can reach, serve them over a path that only the PKI cluster can write to, and monitor them for unexpected changes. Confirm how your OpenBao version exposes these endpoints and whether they require authentication.

Enable audit devices for issuance and revocation

Enable at least one audit device so that certificate issuance, role changes and revocations are recorded with the identity that performed them. Send the logs to a store that the PKI administrators cannot edit, and test that a sample revocation produces the expected entry. Check the audit behavior of your OpenBao version and confirm how sensitive fields are handled before you forward logs.

How to test that the CA issues correctly and fails safely

Testing an OpenBao certificate authority means proving three things before anyone relies on it: the chain validates, issuance follows the role you designed, and the system behaves predictably when a node fails during issuance. Treat these checks as acceptance criteria for the PKI setup, not as a one-time demonstration. Each check below should be written as a script that runs against a non-production mount first and then against the production mount with test identities, so that the same evidence can be regenerated after every configuration change or upgrade. Start with the chain. Export the root and intermediate certificates from the PKI mounts and the leaf certificate issued through the issuing role. Validate the path from leaf to root with standard tooling such as OpenSSL, confirming that each signature verifies, that the intermediate carries the CA basic constraints you intended, and that the root is the only trust anchor you distribute. Then inspect the leaf itself. Confirm that the subject, the subject alternative names, the key usage and extended key usage, and the validity period match what the role is supposed to produce. A lifetime that differs from the role's configured TTL is a defect in either the role or the request path, and the script should fail on it. Next, test the negative cases, because a CA is judged as much by what it refuses as by what it issues. Request a certificate for a name outside the role's allowed domains, request a key type or key size the role disallows, and request a wildcard if the role does not permit one. Each request must be refused with a clear error, and the refusal should appear in the audit device output. Then authenticate as a caller that holds a token without the issuing policy and confirm that the request is denied. Record the exact error text and the policy names involved, since these are the outputs an assessor will ask for. Revocation needs its own sequence. Issue a short test certificate, revoke it through the PKI revoke path, and then fetch the published CRL or query the OCSP endpoint if you have enabled it. Confirm that the serial number appears in the revocation information your clients use. Finally, configure a test client that trusts only your root and confirm that it accepts the unrevoked certificate and rejects the revoked one. The specific revocation endpoints and their availability depend on your OpenBao version and configuration, so confirm them against the PKI documentation for the release you deploy. The failure test asks what happens during issuance when the active node disappears. While a client loop requests certificates, seal or restart the active node, then observe whether the client retries, whether standby nodes take over the active role, and whether any certificate is issued twice or with altered parameters. Record the retry count, the time to recovery, and the errors seen by the client. Keep all scripts, command transcripts and audit logs together as dated evidence. These outputs support your own internal assessments, but they are not an audit result, and they should be reviewed against your own control requirements.

What to monitor, back up and document after the CA is live

A certificate authority is only as trustworthy as its day-two operations. The cards below cover what to watch, what to protect, what to rehearse and what to write down so the PKI keeps issuing valid certificates after the people who built it have moved on.

Monitor certificate expiry

Track the expiry dates of the root, every intermediate and every leaf certificate the OpenBao PKI engine issues, and alert well before each one lapses. Intermediate expiry is the event most likely to break trust across many services at once, so alert on it with the longest lead time. Confirm which alerting tool your team already uses can read certificate data from OpenBao, and test that an alert fires against a certificate with a near expiry date.

Track issuance and revocation volume

Send OpenBao audit device logs to your log platform and build dashboards for certificate issuance and revocation counts by issuing role. Unexpected spikes can point to a misconfigured client, a compromised workload or a role that is too permissive. Confirm which audit fields your platform needs for role-level reporting, because the field names should be checked against the OpenBao version you run.

Back up PKI data and storage

Include the PKI mount data and the storage backend in the same backup procedure, schedule and retention rules used for the rest of the OpenBao cluster. A backup that captures the storage but not the consistent state of the PKI mount, or the reverse, can produce a CA that cannot be restored. Record who holds backup encryption keys and where backups are stored, and keep that record outside the cluster.

Test CA restore regularly

Restore the backed-up CA into a separate environment on a fixed schedule and confirm that the restored instance can read its keys, sign a test leaf certificate and reach the revocation endpoints. An untested backup is an assumption, not a recovery plan. Record the restore duration and any manual steps, and treat each undocumented step as a gap to close before the next test.

Plan intermediate rotation and root re-keying

Treat intermediate rotation and root re-keying as planned future events, not as emergencies. Decide the trigger for each, such as a scheduled lifetime, a suspected key exposure or a change in algorithm policy, and document the trust chain each event will change. Root re-keying affects every client that pins or distributes the root, so schedule it with the owners of those clients and confirm the procedure against the OpenBao PKI documentation for your version.

Review roles and policies on a schedule

Set a recurring review of every PKI issuing role, the allowed domains, maximum time-to-live values and the policies that grant access to issue or revoke certificates. Remove roles that no longer match a workload and compare the live configuration against the role inventory, so drift is caught. Assign a named owner to each role so reviews have someone accountable for the answer.

Keep emergency and trust-move runbooks

Write two runbooks before they are needed: one for emergency revocation of a leaf or intermediate certificate, and one for moving trust to a new intermediate. The revocation runbook should name who can trigger it, how clients learn of the change and how the revocation is verified. The trust-move runbook should cover distribution of the new chain, overlap periods and the removal of the old intermediate.

Check PKI compatibility on upgrades

Before each minor OpenBao upgrade, check the release notes for changes to the PKI secrets engine, including behavior of issuing roles, signing and revocation. Test the upgrade against a copy of your PKI configuration in a non-production cluster, and confirm that issued certificates and the CRL behave as expected. The rolling upgrade procedure for the cluster itself is covered in the OpenBao upgrades and support topic.

What buyers ask before building an OpenBao certificate authority

What does it cost to build an OpenBao certificate authority?

The cost is the implementation effort, plus the infrastructure and key management you run afterward. OpenBao is licensed under MPL-2.0 and has no license fee or paid edition, so the spend is people, cloud or data center capacity, and the systems that protect the unseal material. The biggest drivers are how many certificate authorities you need (a single root or a root with intermediates across environments), how many issuing roles and applications must be onboarded, whether certificates must integrate with Kubernetes, load balancers or device enrollment, and how much of the root key custody process must be documented for auditors. A figure comes from the written scope, which lists these components and their deliverables before work starts. Ask any quote to separate one-time design and build work from recurring operations and renewal support.

How long does an OpenBao PKI rollout take?

Duration depends on scope and on how quickly your team can provide inputs, so no general timeline applies. The main drivers are the number of CA tiers, the storage backend and high availability design, the unseal approach, and how many certificate consumers must switch to the new issuing roles. Delays usually come from waiting on decisions about root custody, change approvals for production windows, and inventories of existing certificates that were never recorded. Work that runs in parallel, such as building lab environments while the custody model is approved, can shorten the path. Your scope document should set out the phases, the dependencies on your team and the milestones, and it is the source for any duration you are asked to plan around.

What do we need to provide before an OpenBao CA build starts?

Four inputs matter most. First, access to the target cluster or hosting accounts, with the network paths and approvals needed to reach them. Second, a named owner for root key custody who can sign off on ceremony steps, key holders and storage of recovery material. Third, change windows agreed with operations for any step that touches production trust chains. Fourth, a certificate inventory covering what is issued today, by whom, to which systems and with what lifetimes, because the migration plan depends on knowing which endpoints will break when a chain changes. Teams that cannot yet name these owners usually need a discovery step first. Confirm each input with your security and platform leads before the quote is finalized.

Can our own engineers build and run OpenBao PKI without a partner?

Yes, if your team has experience with PKI design, OpenBao or Vault operations, and Linux and networking administration. The PKI secrets engine has a large surface: root and intermediate design, issuing roles with constrained names and key types, short-lived certificate issuance, revocation and CRL distribution, and audit logging. Engineers who have not built a CA before tend to underestimate the ceremony and documentation work, and the failure modes are costly because a wrong chain or lost key affects every service that trusts it. A partner can supply a second set of hands for the design review, the ceremony and the test plan. Your team should decide based on existing skills, staffing during the build window, and how much of the work must be independently evidenced.

What does our team own after an OpenBao CA handover?

You own the running system, its keys and its operating procedures after handover. That includes monitoring the cluster, rotating and renewing intermediate certificates on schedule, managing issuing role changes, handling revocation requests, applying OpenBao minor releases and security patches, and keeping root key custody records current as people change roles. Documentation delivered with the build should cover the design, the ceremony records, the runbooks and the test results so that your own staff can operate the CA. DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your infrastructure, and ongoing support, upgrades and continuous testing are available as retainers. Ask for the handover list in the written scope so ownership of each item is explicit.

Does DeployOpen provide a fixed-scope quote for an OpenBao certificate authority?

Most DeployOpen engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so the quote follows from that written scope. To get a useful quote, provide the number of certificate authority tiers, the environments in scope, the storage and high availability requirements, the unseal approach, the expected issuing roles and consumers, and the inventory status. Ask the quote to state what is excluded, such as application changes on your side, third-party certificate authorities, and retainer support after handover. A scope that lists assumptions about your inputs is easier to hold both parties to than one that does not.

How do we check that an OpenBao PKI build is working as designed?

Verification should prove the chain, the issuing rules and the revocation path, not only that the service is running. Check that each intermediate chains to the intended root, that issuing roles only produce certificates for the names and key types they permit, that short-lived certificates renew without manual steps, and that revoked certificates appear in the revocation information clients use. Test cluster failover while certificates are being issued, and confirm audit records capture issuance and administrative actions. Ask for the test plan and results as part of the deliverables, and confirm with your auditors which evidence they expect for the control objectives you must meet.

How DeployOpen scopes, builds and hands over an OpenBao PKI

DeployOpen plans, implements, documents and supports OpenBao inside your own infrastructure, including the PKI secrets engine used as an internal certificate authority. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.

How we scope

Agree which certificate types, domains and workloads the internal CA must issue before any design work starts.
Define the root and intermediate hierarchy, key custody approach and where each CA signing key will live.
Record issuing roles, maximum certificate lifetimes and revocation expectations in the written scope and deliverables list.

How we build

Build the root and intermediate CAs in the PKI secrets engine, with roles that restrict names, key types and lifetimes.
Configure short-lived certificate issuance and test renewal paths against sample workloads in a non-production environment.
Test revocation, certificate revocation list publication and failure handling before anything moves toward production.

How we hand over

Document the CA hierarchy, issuing roles, policies and runbooks so your engineers can operate the PKI without us.
Walk your platform and security teams through issuance, renewal, revocation and incident procedures on your own systems.
Deliver configuration as code and a handover record listing owners, access paths and open decisions for your review.

How we support

Offer ongoing support, upgrades and continuous testing for the PKI as a retainer, scoped in writing.
Review OpenBao release notes and PKI-related changes when a new version is adopted, and plan the upgrade with your team.
Confirm with your auditors or assessors which evidence they need from the CA, since DeployOpen prepares evidence but does not issue assessments.