Can OpenBao or Infisical replace Azure Key Vault certificate issuance?
If your renewal bill for Key Vault certificates has become hard to predict, or if policy requires certificate issuance to stay inside your own environment, the short answer is that OpenBao's PKI secrets engine and Infisical's private PKI both cover issuance and renewal for internal certificates. Services can request X.509 certificates without someone generating keys and certificate signing requests by hand, and short lifetimes reduce how often revocation is needed. Certificates from public certificate authorities and certificates that Azure services consume directly are a separate question and need their own checks before you move anything.
A practical split: choose OpenBao's PKI secrets engine if your team already runs OpenBao for secrets, wants certificates issued by policy from the same identity and audit model, and is comfortable operating a Vault-style service. Choose Infisical's private PKI if developers and platform teams mainly want ACME or EST enrollment alongside secret syncs and a management dashboard. Check the enrollment protocol each workload needs before you decide, because Infisical's ACME and EST support is documented for its private PKI, and OpenBao's PKI engine is driven through its API and its own configuration. Confirm the details against the OpenBao PKI secrets engine documentation and the Infisical README.
App Service is the case that needs the most care. Certificates used for App Service custom domains, bindings and managed certificates depend on how Azure retrieves and renews them, and a private CA issued through OpenBao or Infisical is not automatically accepted by those bindings. For each App Service workload, list every certificate it uses, record where it is stored, whether it is a public or private chain, and how renewal is triggered today. Then confirm with Microsoft documentation and a test deployment whether the Key Vault certificate features that workload depends on have an equivalent. Until that inventory is complete, treat the replacement as a per-workload decision rather than a vault-wide switch.
Which Key Vault certificate capabilities map to OpenBao and Infisical
This table maps each Key Vault certificate capability to OpenBao's PKI secrets engine and Infisical's private PKI, and flags where you must verify fit yourself. Read the gap rows first, because public CA integration and Azure-native binding decide how much of the current setup you can keep. Most teams find that issuance and renewal map well, while App Service binding and public CA paths need a separate design.
| Capability | OpenBao PKI secrets engine | Infisical private PKI |
|---|---|---|
| Issuance of X.509 certificates from an internal CA | Dynamic certificates issued by PKI roles, so services need no manually created keys or signing requests | Private CA issues X.509 certificates managed in the Infisical project |
| Short-lived certificates and renewal | Short TTLs are recommended so fewer revocations are needed; renewal is driven by the client | Automated renewal through ACME or EST enrollment; confirm renewal behavior for your clients |
| Automated enrollment by clients | Client-side tooling or agents must request and install certificates; confirm the agent you choose | ACME and EST enrollment support for clients that speak those protocols |
| Certificate policies and key types | Roles define allowed domains, key types and TTLs; review them against your current Key Vault policies | Certificate templates and policy settings; confirm each setting you rely on in Key Vault |
| Key storage and protection | Keys are handled by the engine and stored encrypted in OpenBao storage; HSM options need separate design | Key management service for encrypt and decrypt; confirm where private keys are held and HSM support |
| Public CA integration | Gap to verify: the engine is an internal CA, so public certificates need a separate path or a provider | Gap to verify: confirm whether any public CA connector exists before planning public certificates |
| Azure-native retrieval and binding for App Service | Gap: App Service certificates do not read from OpenBao, so export or a sync step is required | Gap: no native App Service binding is documented in the supplied material; confirm with the vendor |
OpenBao PKI or Infisical private PKI: when each fits
Both OpenBao and Infisical can issue and renew X.509 certificates in your own infrastructure, so the choice depends on what else you run alongside them. The cards below compare issuance model, enrollment, licensing and operating scope so you can match the engine to your Key Vault certificate workloads.
OpenBao PKI secrets engine
The PKI secrets engine issues dynamic X.509 certificates on request, so services do not need to create keys and certificate signing requests by hand. OpenBao recommends short TTLs so fewer certificates need revocation, which changes how you plan renewal for App Service and other Azure consumers. Check whether your consumers can fetch certificates from OpenBao's API or need a sidecar or agent that writes files and reloads the process.
Shared service with other secrets
If you also move application secrets, dynamic database credentials or encryption as a service into OpenBao, certificates run on the same cluster, auth methods and audit path. That reduces the number of systems to patch and back up, but it also means a PKI outage or misconfigured mount can affect other workloads. Confirm the HA design, storage backend and backup plan before placing a certificate authority on the same service.
Infisical private PKI and enrollment
Infisical's private PKI supports ACME and EST enrollment, which suits devices and servers that already speak those protocols. Certificates can be requested through standard clients rather than custom integration code. Confirm which ACME clients and EST flows your Azure workloads and network devices support before you choose this path.
KMS and PAM in one product
Infisical also includes a key management service for encrypt and decrypt operations and privileged access management with session recording. If you want certificates, keys and privileged sessions managed under one console and one RBAC model, this consolidation is the main reason to choose it. Verify that the features you need are in the self-hosted edition you plan to run, not only in the hosted service.
Enterprise licensing for self-hosting
Infisical's self-hosting documentation says enterprise features such as SSO and gateways need enterprise licensing. Under a Key Vault model, Azure Entra ID integration is part of the bill you already pay, so the comparison has to include the license fee for Infisical as a cost line. Ask the vendor for the license terms and price in writing, and confirm whether your certificate workflow depends on any gated feature.
Who operates the authority
Either option makes your team responsible for the certificate authority hierarchy, root key protection, CRL or OCSP publication and renewal monitoring. Key Vault handles much of that operation for you. Decide who owns root and intermediate key ceremonies, where unseal or key material lives, and how an expired intermediate would be detected before it breaks App Service bindings.
What changes for App Service and other Azure consumers
Moving certificate issuance to OpenBao does not, by itself, change anything that already consumes certificates from Key Vault. App Service and other Azure services typically pull certificates through Azure-native bindings, such as a Key Vault reference or a certificate imported into the service, and those bindings keep pointing at the vault and its current certificate object. Before any cutover, inventory every consumer that references a Key Vault certificate, record the resource, the binding type and the owner, and confirm with Microsoft's current documentation for each service how it imports, renews and reloads certificates. Do not assume a renewal in OpenBao will reach a binding that never reads from it.
For each consumer, decide how the new certificate will be delivered. One option is to keep Key Vault as the delivery point and write the OpenBao-issued certificate into it on each renewal, so existing bindings continue to work unchanged. Another is to re-point the consumer to a different source and redeploy its binding. Confirm for every service which certificate formats it accepts, such as PEM with a separate private key or a PFX bundle, whether it requires a password on the bundle, which chain order it expects, and what triggers a reload after a certificate changes. Test one non-production consumer end to end, including the renewal event, before changing production bindings.
Key Vault should stay where it is for any service that depends on it for customer-managed keys or for certificates that Azure itself manages, and it should remain in place during the transition so that rollback is possible. Plan for a period in which both issuance paths exist, and record which certificates are issued by which system. Ask each Azure service owner and, where needed, Microsoft support to confirm the supported delivery paths for your service tier and region before retiring any Key Vault certificate object.
Moving certificate issuance and renewal out of Key Vault
This sequence moves certificate issuance and renewal from Key Vault to OpenBao or Infisical in an order that keeps every consumer working throughout, and ends with Key Vault renewals switched off. The output is a documented inventory, a CA design, a running PKI service and a cutover record that your auditors and on-call team can follow.
Inventory certificates and their consumers
Export the certificate list from each Key Vault, including issuer, validity period, renewal policy, key type and the private key location. For every certificate, record which App Service, Application Gateway, Kubernetes ingress, load balancer, VM or application reads it, and how it is loaded (Key Vault reference, managed identity, pipeline or manual install). Done when every certificate has a named owner and at least one consumer listed, and the list has been reviewed by the application teams. Ask the vendor or your Azure administrator to confirm which services read certificates directly from Key Vault, because the list determines your cutover order.
Decide the CA hierarchy and certificate TTLs
Choose whether certificates come from a private root and intermediate CA inside OpenBao or Infisical, from a public CA through ACME, or from both. Assign a TTL to each certificate class, and note OpenBao's recommendation of short TTLs, which reduces the number of revocations you must handle. Record the decision in a short design note that names the key type, the signing policy and who approves changes. Done when the design note is approved by security and the platform owner, and every certificate class in the inventory maps to one issuer and one TTL.
Stand up the PKI engine or Infisical PKI
Deploy OpenBao with its PKI secrets engine, or deploy Infisical with its private PKI, in your own infrastructure. Configure the root and intermediate CA, roles that enforce allowed names and TTLs, and access policies so only the approved automation can request certificates. Store the root key under the protections your policy requires and confirm the CA chain validates on a test client. Done when a test certificate issues through the intended role, chains to the trusted root and is logged in the audit trail. Confirm with the vendor which key protection options your edition supports before choosing storage.
Issue parallel certificates for each consumer
For each certificate in the inventory, issue a new certificate from the new CA alongside the existing Key Vault certificate. Where a consumer needs a private key, generate the key inside the new platform and deliver it through the mechanism the consumer supports. Where Key Vault holds a non-exportable private key, plan to re-issue a new key pair rather than attempt an export. Done when each parallel certificate is stored in a staging location, its subject alternative names match the inventory, and the owner has confirmed it is correct.
Re-point consumers to the new certificates
Switch each consumer to the new certificate, one service at a time, starting with the lowest-risk items. Update bindings in App Service, load balancers, ingress controllers or application configuration, and keep the old Key Vault certificate in place until the switch is verified. Ensure the trust chain is installed on clients that do not trust the new root. Done when each consumer serves the new certificate, health checks pass and the owner signs off on the change record. Note that Azure services which need Key Vault for customer-managed keys remain on Key Vault, so exclude those from this cutover.
Automate renewal and shorten TTLs
Replace manual renewal with automated enrollment, using OpenBao's API or ACME and EST enrollment in Infisical, and configure consumers to fetch renewed certificates before expiry. Once automation works, reduce TTLs in stages according to the design note from the second step. Monitor expiry and renewal failures with alerts that reach the on-call team. Done when every certificate renews without manual action across at least one full renewal cycle for the shortest TTL in use, and alerts have fired and been resolved in a test.
Retire Key Vault renewals and record the cutover
Disable auto-renewal and certificate issuance policies in Key Vault for the migrated certificates, and remove any remaining consumer references. Keep Key Vault soft-delete and backup data for the retention period your records policy requires before removing anything. Record the final inventory, CA details, owners and approvals in your change management system so assessors can trace each certificate. Done when Key Vault no longer issues or renews migrated certificates, the inventory shows zero active consumers on Key Vault for those items, and the cutover record is filed. Ask your compliance team which evidence they need, since DeployOpen prepares evidence but does not issue audit reports.
Questions buyers ask before replacing Key Vault certificates
What drives the cost of replacing Key Vault certificate renewals?
The main cost driver is how many certificates you issue and renew, how often they renew, and who operates the service. Key Vault bills per operation and per renewal request, so check Microsoft's published Azure Key Vault pricing page or request a quote that reflects your certificate volume. Self-hosted OpenBao or Infisical replaces those charges with recurring infrastructure, storage, backups and staff time, plus one-time design and migration work. Short certificate lifetimes increase renewal frequency, so automation matters more than the platform fee. Ask any implementation partner for a written breakdown of one-time versus recurring costs, the assumptions behind the certificate count, and who pays for on-call support.
How long does a pilot for self-hosted certificate issuance take?
The duration depends on the scope agreed in writing before work starts, and no fixed timeline applies to every environment. A pilot usually moves faster when you can supply a complete inventory of certificates, their consumers and renewal dates. You will need to provide DNS control or the challenge method your certificate authority requires, a place to run the service (such as a Kubernetes cluster where the OpenBao Helm chart, which requires Helm 3.6 or later, can be installed), identity sources for workloads, and a named owner for App Service and other Azure consumers. Confirm with your team and any engagement partner which certificates the pilot covers and what success looks like.
Can OpenBao or Infisical still issue public CA certificates?
Confirm this before committing, because the answer depends on your certificate authority and the tool you choose. The OpenBao PKI secrets engine issues dynamic X.509 certificates from the CA hierarchy you configure, which is the strongest fit for internal services. Infisical's private PKI supports ACME and EST enrollment, so check whether your public CA accepts ACME requests in the way your configuration needs. Ask the public CA for its ACME support, domain validation requirements and any account limits. Test one public certificate end to end in the pilot before moving production domains, and confirm that the renewal path works without manual steps.
Can our internal team run this without outside help?
A capable platform team can run a self-hosted certificate service, but the first build needs clear ownership and PKI experience. The work includes designing the CA hierarchy, protecting root and intermediate keys, choosing short lifetimes, distributing trust chains and setting renewal hooks for each consumer. OpenBao is open source under MPL 2.0 and documents its PKI secrets engine, so the software itself is available to your team without a license fee. Infisical's self-hosting documentation states that enterprise features such as SSO or gateways require enterprise licensing, so confirm which features you need. DeployOpen can plan, implement, document and hand over the service in your environment, under a fixed scope agreed in writing.
What does ongoing operation of a self-hosted certificate service require?
Ongoing operation covers the platform and the certificates it issues. Plan for these recurring tasks:
- Upgrades, including security releases such as OpenBao v2.7.1, released on October 1, 2026, and Infisical's regular releases
- Backups and tested restores of the storage backend and CA material
- Monitoring of certificate expiry, renewal failures and service health
- Protection of CA keys, access reviews and audit logs for issuance events
- On-call coverage for renewal failures that affect production traffic
The effort rises with the number of consumers and the speed of renewal. Ongoing support, upgrades and continuous testing are available from DeployOpen as retainers, which you can compare with keeping these tasks in-house.
How do App Service certificate bindings change after moving?
Bindings change because App Service no longer receives renewed certificates from Key Vault automatically once you move issuance elsewhere. Confirm the current binding method and any Key Vault integration settings in Microsoft's App Service documentation for your plan. In the migration plan, decide for each app whether it receives a new certificate by upload or through a supported import path, then schedule the rebinding and test it in a non-production slot. Short lifetimes mean renewal must be fully automated, so assign an owner to every App Service binding and set alerts for expiry before the next renewal window. Record each binding in your inventory so the cutover order is clear.
Keeping Key Vault where it still fits
Key Vault stays the right store for certificates whose lifecycle is tied to Azure. Before you move anything, list every certificate and check whether the consuming service reads it from Key Vault by design. App Service certificates, certificates bound to Application Gateway or Front Door listeners, and certificates used for Azure-managed custom domains are the usual cases. Confirm each one with the service documentation and with your own deployment, because the Azure side may expect a Key Vault reference, a managed renewal flow or a specific certificate format that OpenBao's PKI engine will not produce on its own. Certificates issued by a public CA through an Azure-integrated flow should also stay put until you have checked who holds the renewal relationship.
Running both stores during transition is workable if each certificate has one owner at any time. Assign every certificate to exactly one system of record, record the cutover date, and keep the Key Vault copy in place until the consumers have been verified against the new issuer. Document the trust boundaries explicitly: which CA signs which certificate, where each private key is generated and stored, which identities can request issuance, and which chains clients must trust. Mixed chains are a common failure point, so test the full chain from each client type, including services that pin roots or hold their own trust bundles.
An auditor will look for a design record, not a claim of compliance. Expect to be shown an inventory of certificates with their issuing CA, owner, renewal path and expiry monitoring; the role and policy definitions that govern who can issue; logs of issuance and revocation; and evidence that private keys never left the intended boundary. Ask your assessor which control families they will map these artifacts to. Independent auditors and certification bodies decide whether the evidence is sufficient. DeployOpen can prepare the systems, configuration and evidence for that review, but it does not issue audit reports or attestations.
How DeployOpen scopes and delivers certificate replacement
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Key Vault certificate replacement, that means mapping your current certificate inventory and renewal flows onto OpenBao's PKI secrets engine or Infisical's private PKI, under a written scope agreed before work starts.
How we scope
- Inventory every certificate, issuing CA, renewal trigger and Azure consumer that depends on Key Vault today.
- Agree in writing which consumers move to short-lived certificates and which stay on public CA certificates.
- Define deliverables, timelines and acceptance tests for each in-scope certificate flow before implementation starts.
How we build
- Deploy the chosen platform in your infrastructure, with the storage backend and high availability design agreed in scope.
- Configure the PKI hierarchy, ACME or EST enrollment, and integrations with public CAs where the scope requires them.
- Test issuance, renewal, revocation and application reload behavior against each consumer, including App Service bindings where applicable.
How we hand over
- Document the PKI architecture, issuance policies, TTL choices, renewal runbooks and recovery procedures for your team.
- Provide evidence of configuration and test results that your internal or external auditors can review, without issuing any audit opinion ourselves.
- Walk your operations staff through day-to-day certificate operations, alerting and incident handling before the scope closes.
How we support
- Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as a retainer.
- Retainers can cover platform upgrades, such as moving between OpenBao releases, with changes tested before rollout.
- Ask any provider to confirm, in the quote, who is responsible for backups, CA key custody and after-hours response.
