Start with Identity
Subscribe
Tools

Top 6 Open-Source PKI and Certificate Management Tools

The best open-source PKI tools in 2026, from EJBCA and step-ca to Dogtag, cert-manager, OpenXPKI, and Boulder, compared on protocol support, automation, and who each fits as certificate lifetimes shrink.

By SWI Community TeamUpdated 2026-08-2914 min read
Key takeaways
  • Shrinking public certificate lifetimes have made manual renewal unworkable, so the decisive question for a PKI tool in 2026 is not what it can issue but how completely it automates issuance and renewal.
  • The leading open-source options are EJBCA, step-ca, Dogtag Certificate System, cert-manager, OpenXPKI, and Boulder.
  • Match the tool to the estate: EJBCA and Dogtag for full enterprise CA hierarchies with SCEP and CMP, step-ca for lightweight internal CAs with ACME, cert-manager for Kubernetes lifecycle, and Boulder if you are running ACME issuance at scale.

Certificates are machine credentials, and most organizations manage them worse than they manage passwords. The reason is that expiry is the only failure mode that announces itself, so PKI gets attention once a year when something breaks. That is changing for a structural reason: the CA/Browser Forum has set a schedule reducing maximum public TLS certificate lifetimes toward 47 days by 2029, and at that cadence manual renewal is not a process, it is a scheduled outage.

That makes automation the deciding criterion for tool selection rather than a nice-to-have. This guide covers the six open-source projects worth knowing, from full enterprise certificate authorities to Kubernetes-native lifecycle automation. For the commercial landscape see the PKI vendor category, and for the concepts, PKI, X.509, and certificate lifecycle.

Evaluation Criteria

We assessed each tool against the following dimensions:

  • Protocol support, ACME, SCEP, CMP, EST, and REST APIs
  • Automation, how completely issuance and renewal can run unattended
  • Hierarchy support, root and intermediate CA management
  • Revocation, CRL and OCSP capability
  • Key protection, HSM and PKCS#11 support
  • Operational burden, what running it properly actually requires
  • Ecosystem fit, Kubernetes, directory, and workload identity integration

The Top 6 Open-Source PKI Tools

1. EJBCA Community

Best For: Full enterprise certificate authority requirements with broad protocol support.

Overview

EJBCA is the most widely deployed open-source enterprise CA in production, originally built by PrimeKey and now part of Keyfactor. It is a Java platform providing CA, registration authority, and OCSP responder functionality, supporting X.509 and SSH certificates, with CMP, SCEP, EST, ACME, and REST interfaces. Community Edition is open source; Enterprise adds support, hardware appliance options, and additional features.

Key Features

  • Full CA hierarchy management with multiple CAs in one instance
  • CMP, SCEP, EST, ACME, and REST enrolment protocols
  • OCSP responder and CRL generation
  • PKCS#11 HSM integration for key protection
  • X.509 and SSH certificate issuance

License LGPL-2.1 for Community Edition; Enterprise Edition is commercially licensed.

Pros

  • The broadest protocol coverage in open-source PKI, which matters for device and network estates
  • Genuine enterprise track record with HSM support
  • Clear commercial upgrade path if you need support

Cons

  • Heavy: Java application server deployment with a real learning curve
  • Community and Enterprise feature split is significant
  • Overkill if you only need internal TLS certificates

2. step-ca (Smallstep)

Best For: Lightweight internal certificate authorities with ACME-first automation.

Overview

step-ca from Smallstep is an online CA designed around automation from the start. It speaks ACME, so anything that can renew a Let's Encrypt certificate can renew an internal one, and it supports short-lived certificates, SSH certificate issuance, and provisioners that tie issuance to OIDC identity, cloud instance identity, or JWK. It is a single Go binary, which makes the operational story dramatically simpler than EJBCA's.

Key Features

  • ACME server for internal certificates, plus its own API
  • SSH certificate authority alongside X.509
  • Provisioners tied to OIDC, cloud instance identity, and Kubernetes
  • Short-lived certificate issuance as a first-class pattern
  • Single binary deployment

License Apache 2.0.

Pros

  • The easiest path from no internal PKI to automated internal PKI
  • ACME support means existing tooling works unchanged
  • SSH certificates remove the standing-key problem alongside TLS

Cons

  • Not a full enterprise CA: no SCEP or CMP for device estates
  • Smaller feature surface for complex hierarchies
  • Online CA model needs careful root key handling

3. Dogtag Certificate System

Best For: Red Hat and FreeIPA environments needing an integrated enterprise CA.

Overview

Dogtag is a full-featured certificate system supporting X.509 issuance, CRL generation, and ACME, SCEP, and REST interfaces, and it is the certificate authority embedded in FreeIPA. If you already run FreeIPA for Linux identity management, you have Dogtag, and using it as your internal CA avoids introducing a second system. Standalone deployment is possible but less common.

Key Features

  • Full CA with certificate profiles and approval workflows
  • CRL generation and OCSP responder
  • ACME, SCEP, and REST enrolment
  • Key recovery authority for escrow scenarios
  • Integrated into FreeIPA for Linux estates

License GPL-2.0.

Pros

  • Already present and integrated if you run FreeIPA
  • Mature, with certificate profiles and approval workflow
  • Key escrow capability that most alternatives lack

Cons

  • Complex to run standalone
  • Documentation is thinner outside the FreeIPA context
  • Java-based with a heavier footprint than step-ca

4. cert-manager

Best For: Automating certificate lifecycle inside Kubernetes, whatever CA you use.

Overview

cert-manager is not a certificate authority: it is the controller that gets certificates from one and keeps them renewed. It supports Let's Encrypt over ACME, private CAs, Vault or OpenBao, Venafi, and self-signed issuers, exposing certificates as Kubernetes custom resources with automatic renewal before expiry. As lifetimes shrink, this is the difference between certificates being infrastructure and certificates being incidents.

Key Features

  • Certificates as Kubernetes custom resources with automatic renewal
  • Issuers for ACME, private CA, Vault or OpenBao, and commercial CAs
  • Ingress and service mesh integration
  • trust-manager for distributing trust bundles across the cluster
  • Expiry monitoring and events

License Apache 2.0, CNCF graduated project.

Pros

  • Solves the actual failure mode, which is renewal rather than issuance
  • Works with whatever CA you already have
  • Ubiquitous in Kubernetes, so knowledge is easy to hire for

Cons

  • Kubernetes-only, so VM and appliance estates need something else
  • Issuer misconfiguration fails in confusing ways
  • Adds a critical controller to the cluster

5. OpenXPKI

Best For: Organizations wanting a full PKI platform with workflow and approval built in.

Overview

OpenXPKI is a Perl-based enterprise PKI platform that emphasizes configurable workflows: certificate requests can route through approval steps, four-eyes checks, and role-based operations before issuance. It supports SCEP, EST, ACME, and REST, along with CRL and OCSP. It is less known than EJBCA but is a serious option where the process around issuance matters as much as the cryptography.

Key Features

  • Configurable issuance workflows with approvals and dual control
  • SCEP, EST, ACME, and REST enrolment interfaces
  • Role-based web UI for operators and requesters
  • CRL and OCSP support
  • HSM integration through PKCS#11

License Apache 2.0.

Pros

  • Workflow and approval capability that most open-source CAs lack
  • Good protocol coverage for device enrolment
  • Genuinely open licence with no feature gating

Cons

  • Perl stack is unfamiliar to most infrastructure teams today
  • Smaller community than EJBCA
  • Configuration is powerful and correspondingly intricate

6. Boulder

Best For: Running ACME certificate issuance at scale, as Let's Encrypt does.

Overview

Boulder is the ACME server implementation behind Let's Encrypt, written in Go by the Internet Security Research Group and released as open source. It is not designed as a general-purpose internal CA and the project is explicit that it targets Let's Encrypt's own use case, but for organizations that need to operate ACME issuance at very large scale it is the reference implementation with the most production exposure of any ACME server in existence.

Key Features

  • Production ACME server implementation, RFC 8555
  • Designed for very high issuance volume
  • Certificate Transparency log submission
  • Rate limiting and validation infrastructure
  • Battle-tested at internet scale

License Mozilla Public License 2.0.

Pros

  • The most heavily exercised ACME implementation available
  • Genuinely open and developed in public by a non-profit
  • Correct by necessity, since it issues for a large share of the public web

Cons

  • Not built as a drop-in internal CA, and the project says so
  • Operationally complex, with multiple services to run
  • step-ca is a better fit for almost every internal use case

How to choose

If you run Kubernetes and need internal TLS, cert-manager plus either step-ca or an existing CA as the issuer is the shortest path to something that will not page you at 3am.

If you have device or network estates that enrol over SCEP or CMP, that requirement narrows the field immediately to EJBCA, Dogtag, or OpenXPKI. Consumer-grade ACME-only tools will not serve a fleet of network appliances.

If you already run FreeIPA, use Dogtag rather than adding a system.

If approval workflow is a compliance requirement, OpenXPKI is the only entry here with it built in.

Two operational points apply regardless of choice. Protect the root key properly, offline and ideally in an HSM, because a compromised private CA root is an authentication bypass for everything that trusts it. And solve trust distribution before issuance: a certificate nobody trusts is worse than no certificate, and getting the bundle to every client is the part that is always underestimated. See certificate lifecycle and mTLS.

The open-source identity landscape

This is one of a series covering open-source tooling across every identity category:

Frequently asked questions

What are the best open-source PKI tools in 2026?
The leading open-source PKI tools in 2026 are EJBCA Community Edition, step-ca from Smallstep, Dogtag Certificate System, cert-manager, OpenXPKI, and Boulder. EJBCA is the most widely deployed open-source enterprise CA, step-ca is the lightweight ACME-native option, Dogtag underpins FreeIPA, cert-manager automates certificate lifecycle in Kubernetes, and Boulder is the ACME server behind Let's Encrypt.
Why do certificate lifetimes matter for tool choice?
Because the CA/Browser Forum has set a schedule that reduces maximum public TLS certificate lifetimes toward 47 days by 2029, and shorter lifetimes make manual renewal operationally impossible. A tool without robust automation, ideally ACME, becomes a source of outages rather than a control. Internal PKI is not bound by the same rules, but the same operational logic applies once you have more than a handful of certificates.
What is the difference between a CA and certificate lifecycle management?
A certificate authority issues and signs certificates. Certificate lifecycle management discovers what certificates exist across your estate, tracks expiry, automates renewal, and handles revocation. Many organizations have a working CA and no lifecycle management, which is why expired certificates remain a leading cause of self-inflicted outages. EJBCA, step-ca, and Dogtag are CAs; cert-manager is lifecycle automation inside Kubernetes.
Is running your own certificate authority a good idea?
For internal service-to-service traffic, usually yes, and it is far cheaper than buying certificates for every workload. For anything a public browser will validate, no: use a public CA over ACME. The genuine cost of a private CA is not the software, it is protecting the root key, running revocation infrastructure, and distributing the trust bundle to every client that needs it.
How does PKI relate to machine identity?
A certificate is a machine credential, so every question that applies to a service account applies to it: who owns it, when does it expire, how is it rotated, and what happens if it leaks. Workload identity systems such as SPIFFE and SPIRE issue short-lived X.509 credentials, which is PKI applied to the workload identity problem. Treat your CA as tier-zero infrastructure.
Last reviewed By SWI Community TeamSuggest a correctionHow we research

Related on Start with Identity

Independent editorial review, no sponsorship. See more in our articles and rankings.