Every certificate approved. Every approval provable.

The problem

Shorter lifetimes. Stricter auditors. Same team.

cert-manager solved issuing certificates. It never answered who was allowed to ask, who signed off, or how you prove it a year later. As lifetimes shrink and supervisors tighten, that gap stops being a nuisance and turns into an audit finding.

The deadline

The next step is already scheduled

Public TLS certificates drop to 100 days in March 2027 and 47 days by 2029, with domain validation reusable for only 10 days. Semi-manual renewal processes break at the 100-day step. Private PKI isn't bound by the ballot — but auditors calibrate against it.

What changes for you

Built for the three people who sign off on PKI

Certificate governance fails when it helps one team at the expense of another. OpenPKI is designed so that engineers move faster, compliance gets better evidence, and leadership gets fewer surprises — at the same time.

How it works

Nothing to rip out

Most cert-manager integrations hand each request to an external platform that decides somewhere else. OpenPKI keeps the decision in your cluster: CAs, issuance policies, approvals and the audit log are Kubernetes resources you review in Git like everything else you run.

It connects through the issuer interface cert-manager already exposes, so cert-manager keeps renewing certificates and private keys never leave the cluster. Nothing is forked, nothing is replaced.

1. DefineCAs and issuance policies are Kubernetes resources, reviewed in Git like the rest of your platform.
2. RequestWorkloads and people request certificates as usual. Policy approves — or routes to the right approver.
3. ProveEvery decision lands in a hash-chained log with signed checkpoints. Evidence builds itself.

↔ scroll to see the full flow

Because policy is a Kubernetes resource, a change to who may issue what shows up as a diff in a pull request — reviewed, approved and versioned. The change record is the audit evidence.

$ cat issuance-policy.yaml
# draft API, v1alpha1, subject to change
apiVersion: open-pki.com/v1alpha1
kind: IssuancePolicy
metadata:
  name: payments-workload-mtls
  namespace: payments
spec:
  issuerRef:
    kind: ClusterCertificateAuthority
    name: internal-issuing-ca
  subjects:
    dnsNames: ["*.payments.svc.cluster.local"]
  # checked against the algorithm registry
  keyAlgorithms: [ECDSA-P256, ECDSA-P384]
  maxValidity: 30d
  approval:
    automatic:  # routine requests
      serviceAccounts: ["payments:api"]
    otherwise:
      approverRole: pki-approver
      # approver ≠ requester, enforced
      separationOfDuties: true

$ kubectl apply -f issuance-policy.yaml
issuancepolicy.open-pki.com/payments-workload-mtls created

$ kubectl get approvalrequest req-8f21a3 -o yaml
status:
  outcome: pending
  requestedBy: system:serviceaccount:payments:batch-export
  routedTo: pki-approver
  reason: service account outside automatic scope

▌

Every certificate issued under this policy records which version of the file approved it. Field names are a draft and may change before the first release.

Audit

Evidence your auditor can check without trusting us

Tamper-evidence you have to pay to trust isn't tamper-evidence. That's why the log format and its verifier are open source.

Most tools give you a report and ask you to believe it. OpenPKI writes every issuance, approval and revocation into a hash-chained log first, and regularly signs a Merkle checkpoint over it. Change a single entry and verification fails — visibly.

Checkpoints verify with a standalone tool, independent of the running system. "Please send us screenshots" becomes "here is the proof — check it yourself", for internal audit, external auditors and supervisors alike.

Complete, not just intact

A tamper-evident log only matters if everything is in it. OpenPKI operates the CA itself, so every certificate is recorded as an event before it is signed. With the CA key in an HSM or cloud KMS, there is no way to issue around the log. With a software key, whoever can read the key could, which is why we recommend an HSM or KMS for any CA in audit scope.

The log covers what OpenPKI issues. Certificates from issuers it doesn't operate aren't in it, and we won't pretend otherwise.

Not even your own administrators

Checkpoints are signed with a dedicated audit key, never the CA key. Each one can be timestamped by an external RFC 3161 timestamping authority and sent to your auditor as it is produced. Once a checkpoint has left your infrastructure, rewriting anything before it means the copy your auditor already holds no longer matches.

Compared

Where OpenPKI fits

Most teams either run cert-manager on its own, or bolt an external certificate-management platform on top of it. OpenPKI gives you the governance of an enterprise platform, native to the cluster you already operate.

Typical capabilities of each approach — individual products vary. The OpenPKI column describes the product as designed for its first commercial release.

Formats

One policy for TLS and SSH — ready for what's next

Most organisations govern TLS certificates in one tool and SSH access in another — or not at all. OpenPKI puts both under the same policies, approvals and audit trail, and is designed to extend to eIDAS 2.0 wallet credentials when that market is ready.

Sovereignty

Built for institutions that can't outsource trust

Certificate management is being absorbed into a handful of US security platforms. For regulated Swiss and European institutions, where your certificate authority runs — and whose roadmap it depends on — is no longer a footnote. FINMA is explicit that responsibility for outsourced functions stays with you, including your providers' ability to move to new cryptography.

• Swiss company, Swiss jurisdiction.
• Self-hosted by default: your cluster, your database, your keys.
• Open core you can inspect — no black box between you and your trust anchor.

Open core

Open core means no lock-in

The core — including the audit log and its verifier — is Apache-2.0. If you ever stop paying us, your PKI keeps running and your evidence stays verifiable. That's deliberate: checking your own evidence should never depend on a licence. The commercial tier adds what regulated and at-scale operators need on top.

• Event-sourced core, X.509, SSH, CRD/GitOps integrationapache-2.0
• Delegated RA, qualified & EUDI issuance, multi-tenancy, incident orchestrationcommercial

FAQ

The questions buyers ask first

Who's building it

Built by someone who has run PKI where auditors look

I'm Patrick Ambord. For over twenty years I've worked where hardware, software and security meet: first designing electronics, then building and operating the public key infrastructure that regulated Swiss organisations depend on. Having worked on PKI inside a financial market infrastructure, I know what auditors ask for and what it takes to keep certificates running in production.

• 2024–2026SIX, Crypto Services — cryptographic services behind Swiss financial infrastructure.
• 2017–2024libC Technologies — PKI projects in financial market infrastructure, industry, the public sector and defence.
• BeforeElectronics design at Studer Innotec and Menth Electronique, then a Master in ICT at HES-SO.

OpenPKI is built by one person today, and the product is designed with that in mind: the core is Apache-2.0, it runs in your infrastructure, and your evidence stays verifiable without us. Your risk shouldn't depend on mine.

Patrick Ambord on LinkedIn · ambord.tech

Design partners

Shape it with us — before March 2027

OpenPKI is being built now, together with a small number of regulated design partners. If certificate governance above cert-manager is a live problem for you, this is the moment to influence how it works.