Axelspire

Private PKI Strategy: When to Run Your Own Certificate Authority

At some point in every organisation's certificate management journey, someone asks the question: should we run our own CA?

Public Web PKI vs internal CA: choosing what to delegate versus what you must control, visibility included.
Public Web PKI vs internal CA: choosing what to delegate versus what you must control, visibility included.

The question usually surfaces when one of three things happens. The volume of internal certificates outgrows what's practical to manage through public CAs. A service mesh or mTLS deployment requires certificates with lifetimes, key types, or extensions that public CAs don't support. Or the security team raises concerns about certificate visibility — specifically, that every internally-used public certificate exposes subdomain names and infrastructure patterns through Certificate Transparency logs.

The decision to run a private CA is one of the most consequential in certificate strategy. It's the line between consuming certificates as a service and operating a certificate infrastructure. Both are valid. Neither is simple. And the introduction of ACME protocol for internal certificate issuance has fundamentally changed the economics and operational profile of private PKI.

Featured Tool Runs fully in-browser

PKI Health Radar

Drag the sliders to assess your current posture — scores update instantly.

6 more tools: Cost & Risk Explorer Timeline Builder Shadow Heatmap Process Transform Slider Scenario Comparator What-If Demo All tools & guide →

When Private PKI Makes Strategic Sense

Not every organisation needs its own CA. A company running 200 public-facing websites with standard TLS doesn't need private PKI — public CAs handle that use case at scale, with well-understood automation. Private PKI becomes strategically justified when one or more of the following conditions are true.

Certificate volume exceeds what public CAs efficiently serve for internal use cases. Service mesh certificates, database encryption, internal API authentication, container-to-container TLS — these use cases can generate thousands or tens of thousands of certificates. Public CAs charge per certificate, impose rate limits, and require domain validation for every issuance. Private PKI eliminates all three constraints for internal certificates.

You need control over certificate parameters that public CAs restrict. Short lifetimes (minutes or hours for service mesh), custom extensions, non-DNS-name subjects, specific key types or sizes, or certificate profiles that don't conform to the CA/Browser Forum Baseline Requirements. Public CAs are bound by these requirements for publicly trusted certificates. Your private CA isn't.

CT log exposure is a concern. Every publicly trusted certificate appears in CT logs, which are publicly searchable. For organisations that consider their internal service names, infrastructure topology, or subdomain structure sensitive, private PKI avoids this exposure entirely. This is a real consideration for organisations in defence, financial services, or competitive technology sectors.

Regulatory requirements mandate control over the certificate lifecycle. Some regulatory frameworks — SOX key management controls, HIPAA audit requirements, PCI DSS for payment infrastructure — require levels of control, audit trail, and key ceremony documentation that are easier to achieve with infrastructure you operate than with infrastructure a third party operates.

mTLS or client certificate deployments require a trust anchor you control. When you're issuing client certificates for device or user authentication, you need a private CA. Public CAs don't issue client certificates at the volumes and lifetimes that enterprise mTLS typically requires. See mTLS and Client Certificate Strategy for the deployment considerations.

If none of these conditions apply, a multi-CA strategy using public CAs is likely sufficient and operationally simpler.

The True Cost of Running a Private CA

The business case for private PKI typically focuses on per-certificate cost savings. It's a compelling number: public certificates cost $X each, internal certificates from our own CA cost effectively $0 per issuance, therefore we save $X × N.

The honest calculation is more nuanced.

HSM infrastructure. A production private CA requires hardware security modules to protect the root and issuing CA private keys. HSMs aren't cheap — network-attached HSMs from vendors like Thales or Entrust range from tens of thousands to hundreds of thousands of pounds, depending on performance requirements and FIPS 140-2/3 certification level. Cloud HSM services (AWS CloudHSM, Azure Dedicated HSM, GCP Cloud HSM) reduce capital outlay but introduce operational dependencies on the cloud provider.

Key ceremony and audit. Root CA key ceremonies — the controlled process of generating and securing root CA keys — require documented procedures, multiple key custodians, physical security controls, and (for regulated industries) witnessed ceremonies. This isn't a one-time cost; CRL signing, certificate issuance policy updates, and subordinate CA provisioning all require ceremony-grade controls.

Operational staffing. Someone has to operate the CA. CRL distribution, OCSP responder availability, certificate policy management, trust anchor distribution, and incident response all require PKI-specialist knowledge. In many organisations, this knowledge is concentrated in one or two people — a key-person risk that's ironic for a key-management system.

Trust anchor distribution. This is the unglamorous problem that breaks private PKI deployments. Your root certificate needs to be trusted by every system that will validate certificates issued by your CA. For desktops and mobile devices, that means GPO, MDM, or manual installation. For servers and containers, it means baking the root into base images or using configuration management. For third-party systems, it may mean coordinating with vendors. For IoT or OT devices, it may be impossible without firmware updates. Every missed system is a system that will reject your internal certificates.

Ongoing compliance. If you operate in a regulated industry, your private CA infrastructure is subject to audit. Key management practices, access controls, CRL publication, and incident response procedures all need to be documented and demonstrably followed.

The total cost of operating a private CA is typically 5-10× the initial infrastructure cost when you account for staffing, procedures, and ongoing operations. For large organisations with high certificate volumes, the maths still favours private PKI. For mid-size organisations, the calculation is closer than the per-certificate savings suggest.

Internal ACME: Bringing Automation Inside

The single biggest change in private PKI over the past five years is the availability of ACME protocol support for internal certificate authorities. ACME — Automatic Certificate Management Environment, the protocol that powers Let's Encrypt — standardises the certificate request, validation, issuance, and renewal workflow. When the same protocol works for internal and external certificates, automation becomes portable.

Several private CA platforms now support ACME: Smallstep Certificate Authority (step-ca) is purpose-built for ACME-first internal PKI and integrates natively with DevOps tooling. EJBCA (by Keyfactor) supports ACME alongside traditional enrollment protocols. HashiCorp Vault PKI secrets engine can issue certificates programmatically, though it uses its own API rather than standard ACME. OpenBao (the open-source Vault fork) provides the same PKI capabilities. AWS Private CA offers ACME through Connector for ACME, allowing internal certificate issuance via the same protocol used for public CAs. Google Cloud Certificate Authority Service provides managed private CA with ACME support.

The strategic value of internal ACME is operational consistency. Teams that already use ACME for public certificate automation can use the same tools, the same workflows, and the same monitoring for internal certificates. cert-manager in Kubernetes can point at an internal ACME issuer with the same configuration it uses for Let's Encrypt. CI/CD pipelines that request certificates via ACME clients work identically regardless of whether the CA is public or private.

This matters because the operational barrier to private PKI has historically been the bespoke nature of internal certificate enrollment. SCEP, EST, manual CSR generation — each required specialised tooling and knowledge. ACME eliminates that barrier. If your team can configure Certbot, they can configure internal ACME.

The combination of private PKI + internal ACME + short-lived certificates is particularly powerful. Issue certificates with 24-hour lifetimes from your internal CA via ACME, renew automatically every 16 hours, and eliminate the need for internal CRL or OCSP infrastructure entirely. Your revocation strategy for internal certificates becomes passive revocation — stop renewing — which is the simplest and most reliable approach.

Hybrid Architecture: Private + Public

Almost every enterprise needs both private and public PKI. The routing decision — which certificates from which CA — should be explicit in your certificate strategy.

Public CA for externally consumed certificates. Any certificate that needs to be trusted by browsers, mobile devices, or third-party systems should come from a publicly trusted CA. This includes web-facing TLS, email signing (S/MIME), and any certificate consumed by parties outside your organisation.

Private CA for internally consumed certificates. Service-to-service TLS, mTLS client certificates, database encryption, internal API authentication, and Kubernetes service mesh certificates should come from your private CA. These certificates are consumed by systems you control, so trust anchor distribution is feasible.

The grey zone: partner and vendor-facing certificates. B2B API connections, partner integrations, and vendor-facing services occupy a middle ground. If the counterparty can install your trust anchor, private PKI works and gives you more control. If they can't or won't, public CA is the path of least friction.

The routing logic for hybrid architecture should be encoded in your automation platform, not in tribal knowledge. Developers requesting a certificate shouldn't need to know which CA to use — the policy layer should make that decision based on the certificate's intended use, the domain, and the target environment.

Trust Anchor Management at Scale

Trust anchor distribution is the operational challenge that separates organisations that have private PKI from organisations that have private PKI that actually works.

The root certificate of your private CA must be present in the trust store of every system that needs to validate certificates issued by that CA. Missing a single system type creates a failure mode that's difficult to diagnose — TLS connections fail with opaque certificate validation errors that look different on every platform.

Windows endpoints: Group Policy (GPO) distributes root certificates to domain-joined machines. Intune or SCCM handle non-domain-joined or remote devices. The challenge is timing — GPO updates aren't immediate, and there's a window between CA deployment and trust distribution where certificates will be rejected.

macOS and iOS: MDM profiles distribute trust anchors. For unmanaged devices, manual installation via Keychain Access is possible but doesn't scale.

Linux servers and containers: The trust store location varies by distribution (/etc/pki/ca-trust, /usr/local/share/ca-certificates, etc.). Configuration management tools (Ansible, Chef, Puppet) handle distribution, but container base images need to be rebuilt with the new trust anchor. If you use distroless or minimal container images, you may need to mount the trust anchor at runtime.

Kubernetes: cert-manager can manage trust anchor distribution within clusters, but cross-cluster and cross-namespace trust configuration requires careful planning.

IoT and OT devices: This is where trust anchor distribution often fails. Embedded devices, industrial controllers, and legacy systems may have hardcoded trust stores that can't be updated without firmware changes. This is a primary constraint in IoT certificate lifecycle and a key factor in SCEP/NDES legacy decisions.

Third-party applications: SaaS products, commercial off-the-shelf software, and vendor-managed appliances may not accept custom trust anchors. Identify these during planning, not during deployment.

A trust anchor distribution plan should be part of any private PKI business case. If you can't distribute your root certificate to all intended relying parties, your private PKI has a scope limitation that needs to be explicit.

Making the Decision

The decision framework for private PKI comes down to four questions.

Do you have use cases that public CAs can't serve efficiently? (Internal mTLS, service mesh, high-volume internal TLS, custom certificate profiles.) If no, public CAs plus a multi-CA strategy is sufficient.

Can you absorb the operational overhead? (HSM infrastructure, key ceremonies, staffing, trust anchor distribution, CRL/OCSP for non-short-lived certificates.) If the answer is marginal, consider managed private CA services (AWS Private CA, Google CAS, Smallstep managed) that reduce but don't eliminate operational burden.

Can you distribute trust anchors to all intended relying parties? If significant parts of your estate can't accept your root certificate, your private PKI's scope is constrained from the start.

Is ACME support available from your chosen CA platform? If you're going to invest in private PKI in 2025+, ACME support is non-negotiable. The automation benefits are too significant to forego.

Sector guides: Financial services · Healthcare · Manufacturing & OT.

Internal ACME and private hierarchies in hybrid cloud—automation patterns from the public Web, roots you operate.
Internal ACME and private hierarchies in hybrid cloud—automation patterns from the public Web, roots you operate.

← Back to Certificate Strategy: The Framework Most Organisations Skip

Related guides: Regulated PKI implementation, IoT certificate lifecycle.

External References