Skip to content
Axelspire

Private CA Architecture: AD CS vs EJBCA vs step-ca vs Vault PKI

Every organization running internal TLS, mutual authentication, or device identity needs a private Certificate Authority. The default choice for Windows shops has been AD CS since Windows 2000 — but infrastructure has shifted toward containers, multi-cloud, and automation-first workflows AD CS was never designed to serve. This page compares Microsoft AD CS, Keyfactor EJBCA, Smallstep step-ca, and HashiCorp Vault PKI as architectural options—not a flat feature matrix.

Private CA Architecture: AD CS vs EJBCA vs step-ca vs Vault PKI

Section titled “Private CA Architecture: AD CS vs EJBCA vs step-ca vs Vault PKI”

TL;DR: AD CS wins GPO Windows autoenrollment but lacks ACME and cloud-native fit; EJBCA Enterprise is the broadest protocol + compliance play; step-ca is the fastest ACME-first private CA for Kubernetes; Vault PKI is best when Vault is already your control plane—pair with CA architecture and ACME planning.

Overview

Section titled “Overview”

This is an architectural comparison—what each platform does well, where it breaks, and which environments it fits. Use it alongside the deep dives on HashiCorp Vault PKI, Keyfactor Command / EJBCA context, and the vendor comparison matrix for enterprise CLM vs pure CA roles.

Audience: Engineers and security leads evaluating internal PKI, AD CS migration, or Kubernetes certificate issuance—not public TLS CA selection.

Problem Statement

Section titled “Problem Statement”
  • Protocol mismatch: Teams standardize on ACME for servers while AD CS offers RPC/CEP/NDES—automation patterns don’t port cleanly.
  • Single-CA dependency: One legacy CA blocks Linux, containers, and CI/CD unless you bolt on fragile workarounds.
  • Compliance vs velocity: EJBCA Enterprise buys certifications and protocols; step-ca buys speed—choosing wrong wastes license dollars or audit time.
  • Vault confusion: Vault PKI is a CA feature, not a full CLM platform—no cross-CA inventory or discovery by default.
  • Windows vs cloud: GPO autoenrollment is non-optional for many orgs; no open-source drop-in replaces it end-to-end.
  • PQC and algorithms: Long-term post-quantum readiness differs by stack (Java/Bouncy Castle vs Go crypto lag).
  • Operational blast radius: ESC1–ESC13-class issues on AD CS and clustered Java PKI mean architecture and HSM choices matter early.

Failure scenario: Leadership mandates “everything on ACME” while AD CS remains the only approved CA; platform teams deploy shadow CAs or manual exports—trust stores diverge, outages follow renewal gaps, and audit finds untracked issuance paths.

Platform architecture overview

Section titled “Platform architecture overview”

Microsoft AD CS

Section titled “Microsoft AD CS”

Active Directory Certificate Services is a Windows Server role available since Windows 2000 (originally “Certificate Server”). It provides Enterprise CA and Standalone CA modes, with the Enterprise CA integrated into Active Directory for GPO-based autoenrollment, certificate templates, and LDAP-based certificate publishing.

Architecture: AD CS runs as a Windows service on Windows Server. The CA database is JET-based (same engine as legacy Exchange). All CA operations require Windows—no Linux, container, or cloud-native deployment. High availability uses Windows failover clustering (complex). The root CA is typically offline on a separate Windows Server instance.

Protocol support: Enrollment via RPC/DCOM (domain-joined Windows via autoenrollment), CEP/CES (web enrollment), NDES (SCEP for devices), and legacy web enrollment. No ACME, EST, or CMPv2.

Current state (March 2026): Little feature development since Windows Server 2012 R2. Server 2022/2025 include the role without major functional change—no ACME, no API-first automation, no PQC or EdDSA in practice. SpecterOps’ “Certified Pre-Owned” documented ESC1–ESC13 attack paths; several remain relevant in default configurations.

Where AD CS still fits: Windows-heavy environments using GPO autoenrollment (802.1X, smart card, EFS, S/MIME). If consumers are mostly domain-joined Windows and enrollment is template + GPO-driven, AD CS is native. For Linux, containers, IoT, and cloud workloads, it becomes an impediment. → AD CS private CA: business case and fit

Keyfactor EJBCA

Section titled “Keyfactor EJBCA”

EJBCA is a Java-based PKI platform (2001, PrimeKey; now Keyfactor). It is the most feature-complete open-source CA family, with Community (LGPL) and Enterprise (commercial, SLAs).

Architecture: JVM on Linux or Windows; external DB (PostgreSQL, MySQL/MariaDB, Oracle, MS SQL). Multi-node clustering (Enterprise). Docker, Kubernetes (Helm), cloud images, appliance, SaaS. Supports full hierarchy: root, intermediate, RA, VA as separable components.

Protocol support: ACME (RFC 8555), SCEP, EST (RFC 7030), CMP, CEP/CES-style enrollment, REST API. Enterprise adds enhanced protocol and compliance features. SSH certificates supported.

Community vs Enterprise: Keyfactor states Community is not intended for production: no production HA clustering, production HSM support, Common Criteria / FIPS 140-2 certifications, advanced audit/role separation, or commercial SLA. Community is strong for lab; production private PKI usually means Enterprise (quote-based pricing).

Where EJBCA fits: Enterprise PKI needing certifications, multi-tier hierarchy, broad protocols, and vendor support—government, regulated industries, AD CS replacement where protocol coverage must match or exceed AD CS. Closest functional peer to a full commercial CA platform with an open-source lineage. → EJBCA private CA: business case and fit

Smallstep step-ca

Section titled “Smallstep step-ca”

step-ca is an open-source online CA from Smallstep (2019), aimed at automated, API-driven certs for containers, microservices, service meshes, and cloud-native stacks.

Architecture: Single Go binary. Default Badger embedded DB; MySQL/PostgreSQL for HA. Root key generated at init (move offline); running instance is typically an intermediate. Deploy: binary, Docker, or Helm. Horizontal scale needs external DB (Badger is not concurrent-safe for multi-writer HA).

Protocol support: ACME (HTTP-01, DNS-01), OIDC enrollment, JWK tokens, cloud instance identity (AWS/GCP/Azure), SCEP (limited OSS; full dynamic SCEP with Intune/Jamf in Certificate Manager). SSH certificates. OSS has no ACME EAB.

Limitations (by design): Opinionated—single configured intermediate per instance; no supported single-tier “root = issuer”; no OSS web UI; CRL is limited; favors short-lived certs and passive revocation. No built-in enterprise inventory dashboard.

Where step-ca fits: DevOps / platform engineering for mTLS, Kubernetes workload identity, SSH certs, and “our own Let’s Encrypt” mental model. Fastest path to a working private ACME CA. Not the default for multi-tier compliance PKI or native Windows GPO autoenrollment. → step-ca private CA: business case and fit

Commercial: Smallstep Certificate Manager adds hosted/linked authority, UI, device identity, fuller SCEP, EAB, monitoring—per-device / per-workload pricing.

HashiCorp Vault PKI secrets engine

Section titled “HashiCorp Vault PKI secrets engine”

Vault’s PKI secrets engine turns Vault into a CA: dynamic certificates via API, with Vault authn/authz controlling who gets what. For operational depth (scaling, agents, HCP), see the dedicated HashiCorp Vault PKI guide. Summary for this comparison:

Architecture: Feature of Vault, not a standalone CA product. CA key in Vault’s encrypted storage. OSS Vault: active/standby—writes (issuance) hit one node. Enterprise: performance standbys, replication, namespaces, FIPS mode.

Protocol support: Vault API (primary path), ACME since 1.14 (HTTP-01, DNS-01; not TLS-ALPN-01). Enterprise adds EST, CMPv2, SCEP. No end-user web enrollment portal.

Limitations: Not a CLM platform—no discovery across external CAs, no inventory for non-Vault certs. Burst issuance can queue on the active node. ACME is newer than step-ca’s. Vault ops (unseal, storage, upgrades) are non-trivial.

Where Vault PKI fits: Orgs already on Vault; API-first issuance; Kubernetes where Vault is the secrets layer and cert-manager + Vault issuer (or ACME to Vault) is natural; short TTL dynamic certs aligned with Vault’s model. → Vault PKI private CA: business case and fit

Head-to-head comparison

Section titled “Head-to-head comparison”

ACME support

Section titled “ACME support”
PlatformACME
AD CSNone.
EJBCAFull (Community + Enterprise); standard challenges.
step-caFirst-class; HTTP-01, DNS-01; EAB in commercial product.
Vault PKISince 1.14; HTTP-01, DNS-01; no TLS-ALPN-01; default ACME max TTL 90 days (configurable); more latency than native API.

HSM integration

Section titled “HSM integration”
  • AD CS: Windows CNG-compatible HSMs; limited to that stack.
  • EJBCA: Broadest—PKCS#11, CNG, Utimaco, Thales Luna, AWS CloudHSM, Azure Managed HSM; Enterprise FIPS appliance options.
  • step-ca: PKCS#11, YubiKey PIV (HSM image); cloud KMS for CA key storage.
  • Vault PKI: Enterprise auto-unseal with HSM; CA key in Vault storage; managed keys (1.10+) for external KMS—see HSM integration.

Kubernetes integration

Section titled “Kubernetes integration”
  • AD CS: No native integration; cert-manager has no first-class AD CS issuer; community proxies are fragile.
  • EJBCA: Helm; cert-manager / CSR patterns; heavier footprint.
  • step-ca: Helm; cert-manager ACME or Smallstep issuer—lightest footprint of the four in-cluster.
  • Vault PKI: cert-manager Vault issuer or ACME to Vault; incremental if Vault already runs in-cluster.

Scaling characteristics

Section titled “Scaling characteristics”
  • AD CS: Single-server + clustering for HA, not horizontal scale; fine for classic autoenrollment volume, poor for massive automated issuance.
  • EJBCA: Enterprise clustering + DB scaling; proven at very high issuance (e.g. national-scale programs).
  • step-ca: Multiple instances behind LB with shared DB; thousands/day typical; watch ACME concurrency with one account / many orders.
  • Vault PKI: OSS active/standby write ceiling; Enterprise standbys help reads; issuance = writes—see Vault PKI for tuning.

PQC readiness

Section titled “PQC readiness”
  • AD CS: No PQC; tied to Windows CNG evolution.
  • EJBCA: Enterprise PQC direction (e.g. 2025 notes); Bouncy Castle breadth helps private PKI migration planning.
  • step-ca / Vault PKI: Depend on Go crypto; PQC in progress in ecosystem—track NIST PQC and roadmap.

Windows autoenrollment

Section titled “Windows autoenrollment”
  • AD CS: Native GPO—strongest differentiator.
  • EJBCA: CEP/CES-compatible enrollment for GPO → non-Microsoft CA (Enterprise)—common AD CS replacement path.
  • step-ca: No GPO autoenrollment; commercial MDM/SCEP for devices.
  • Vault PKI: No GPO; Enterprise SCEP for devices, not full GPO parity.

Selection decision framework

Section titled “Selection decision framework”

Keep AD CS if the estate is ~90%+ domain-joined Windows, primary use is GPO autoenrollment (802.1X, smart card, EFS, S/MIME), you have no Kubernetes/container cert demand, and Windows admin depth exists. Accept that AD CS won’t expand cleanly to non-Windows.

Choose EJBCA Enterprise if you must replace AD CS with matching protocol breadth, need Common Criteria / FIPS style assurances, run multi-tier regulated PKI, or need Windows autoenrollment against a non-Microsoft CA. Budget for Java ops and commercial licensing.

Choose step-ca if you’re greenfield internal PKI for DevOps, Kubernetes, service mesh, CI/CD, want a private ACME server live quickly, or want SSH + X.509 together. Accept narrow enterprise CA scope (no full CLM in OSS).

Choose Vault PKI if Vault is already central, issuance is API-driven, and you want policy-bound certs without a second CA product. Accept no built-in cross-CA inventory / discovery.

Run two platforms when you need both Windows GPO paths and cloud-native ACME—minimal AD CS (or EJBCA + CEP/CES) for Windows plus step-ca or Vault PKI for the rest. Common hybrid pattern.

Consider a cloud-managed CA when you want zero infrastructure ops for the CA itself. AWS Private CA and Google Certificate Authority Service handle HA, HSM, and patching—at per-cert pricing and vendor lock-in. Pillar is an alternative managed private CA worth evaluating for teams that want a hosted ACME CA without the cloud-hyperscaler dependency. Axelspire has developed a low-cost alternative for low-volume PKIs. It is based on AWS serverless services and uses KMS to provide FIPS140-3 Level 3 security 3am-mint trade-offs.

AD CS migration: common patterns

Section titled “AD CS migration: common patterns”

Pattern 1 — Parallel operation. Deploy step-ca or Vault PKI for new Kubernetes / cloud / CI workloads; leave AD CS for existing Windows autoenrollment. Lowest risk; shrink AD CS scope over time.

Pattern 2 — EJBCA replacement. EJBCA Enterprise with CEP/CES, migrate GPO enrollment, retire AD CS. Full replacement—6–12 months typical for large enterprises; full template and workflow regression testing required.

Pattern 3 — Shrink and contain. Harden AD CS (mitigate ESC issues), restrict to Windows-only autoenrollment, deploy a modern CA for everything else. Pragmatic middle ground.

Regardless of pattern, prefer a new root independent of the AD CS root so cryptographic and organizational independence survives future AD CS retirement.

Operational checklist

Section titled “Operational checklist”
  • Inventory consumers: Windows GPO vs Linux vs K8s vs IoT—document protocol needs (ACME, SCEP, EST, RPC).
  • Automation: Target unattended renewal for server certs (automation readiness, renewal automation).
  • HSM / key protection path chosen per platform (HSM integration).
  • Kubernetes: Confirm cert-manager issuer strategy (ACME vs Vault API).
  • Compliance: If audits require FIPS / CC, shortlist EJBCA Enterprise early.
  • Hybrid: If two CAs, document trust stores, CT (if used), and escalation for distrust or migration (CA distrust playbook).
  • PQC: Record algorithm roadmap per vendor and language runtime.
Section titled “Related documentation”