Private PKI vs Public PKI: Which CA for Which Machine

Putting a machine certificate on the wrong kind of CA either breaks the service or quietly weakens it: public certificates on internal servers publish your internal names and now come with lifetimes and usage rules set by browser vendors, while private certificates on internet-facing services fail for every client you do not manage. The choice is no longer a matter of cost. Public TLS certificates are capped at 200 days from March 2026 and heading to 47 days, every one is logged in Certificate Transparency, and Chrome's root programme is removing client authentication from public TLS hierarchies. This guide maps each machine certificate use case (internet TLS, internal TLS, mTLS, devices, code signing and partner connections) to the right CA type, explains trust distribution and short-lived certificate trade-offs, and covers when to run your own private CA or use a managed one. It is for PKI owners, platform engineers and security architects; the fundamentals are in the PKI Basics Guide.

Key takeaways

The relying party decides. If the client is a browser or device you do not manage, use a public CA; if you control every client's trust store, a private CA is usually the better fit.
Public TLS is now for public TLS only. Under Chrome Root Program Policy 1.8, subscriber certificates issued from 15 March 2027 must assert only id-kp-serverAuth, so plan mTLS client certificates on private CAs.
Every public certificate is published. Precertificates must be logged in Certificate Transparency before issuance from 15 June 2026, so internal hostnames on public certificates become reconnaissance data.
Lifetime rules differ by design. Public TLS falls from 200 to 100 days in March 2027 and to 47 days in March 2029; on a private CA you set lifetimes, and workload certificates of hours or days are normal.
An unmanaged private CA is worse than none. A private root trusted by every endpoint is a master key; if you cannot protect, inventory and rotate it, use a managed private CA.

How the two models differ

A public CA is one whose root is shipped in browser and operating system trust stores under a root programme. To stay there it must follow the CA/Browser Forum Baseline Requirements (version 2.3.1, effective 4 October 2026, when checked in November 2026) and each root programme's own policy. A private CA is any CA whose root you distribute yourself: AD CS, a cloud managed CA, a service mesh CA or an IoT manufacturing CA. The rules are yours, and so is the work of getting every client to trust it.

Property	Public PKI	Private PKI
Who trusts it	Every mainstream browser and OS by default	Only clients whose trust store you configure
Names it can certify	Publicly resolvable domains and public IPs you prove control of; no internal names	Anything you define: internal hostnames, SPIFFE IDs, device serials, user principals
Maximum TLS lifetime	200 days (from 15 March 2026), 100 days (15 March 2027), 47 days (15 March 2029)	Your policy; hours to years
Transparency	Logged to public CT logs; visible to anyone	Private; no external logging unless you add it
Extended key usage	Server authentication only for new TLS subscriber certificates from 15 March 2027 (Chrome)	Any profile you define: client auth, code signing, email, device identity
Validation	Domain control validated by the CA; reuse capped at 200 days now, falling to 10 days in 2029	Your enrolment controls: workload attestation, device management, AD membership
Revocation	CA-operated CRL or OCSP, checked inconsistently by clients	Your CRLs or OCSP, or short lifetimes instead
Main failure mode	Renewal outages, name leakage, policy changes you do not control	Root key compromise, unmanaged CAs, trust store drift

Use case mapping: which certificate goes where

Use case	Recommended CA	Lifetime guidance	Why
Public websites and customer-facing APIs	Public CA via ACME	Maximum allowed today, renew automatically at about two thirds of life	Unmanaged browsers and apps must trust it
Internal web apps reached by managed staff devices	Private CA, or public CA only under a public subdomain you are happy to disclose	90 days or less on private; automate either way	Avoids CT disclosure and public lifetime churn; trust store is managed
Service-to-service mTLS and service mesh	Private CA, often the mesh or a SPIFFE issuer	Hours to a few days	Client authentication EKU, internal identities, high volume
Kubernetes workloads	Private CA through cluster issuers or pod certificates	Hours to days	Identity tied to service account, automatic rotation
Managed laptops and phones (Wi-Fi, VPN, device identity)	Private CA through MDM with SCEP or AD auto-enrolment	About one year, renewed by the MDM	Device identity, client auth, managed trust store
IoT and OT devices	Private CA with a constrained intermediate per product line	Device lifetime for birth certificates; shorter operational certificates through EST	Long-lived devices, manufacturing-time provisioning
Code signing for public distribution	Public code signing CA, key in a hardware crypto module	Up to 460 days for certificates issued from 1 March 2026; always timestamp	Operating systems must trust the signature
Internal-only code, scripts and containers	Private CA or keyless signing with an internal trust root	Short	Only your own verifiers need to trust it
Partner B2B mTLS	Private CA per relationship, or the partner's CA pinned to a specific intermediate	Agreed per partner	Public TLS hierarchies are moving to serverAuth only
Email signing and encryption (S/MIME)	Public S/MIME CA for external mail	Per S/MIME Baseline Requirements	Recipients' mail clients must trust it

For deeper build detail see the mTLS Guide, the Kubernetes Pod Certificates and ClusterTrustBundles Guide, the IoT and Device Certificate Provisioning (EST, SCEP) Guide and the Code Signing Security Guide.

Threat model for public PKI

Reconnaissance through CT: every publicly trusted TLS certificate appears in append-only Certificate Transparency logs, which RFC 9162 describes as publicly auditable. Hostnames such as vpn-legacy.corp.example.com or jenkins-build.example.com on public certificates tell attackers what to probe (ATT&CK T1596.003 Search Open Technical Databases: Digital Certificates). See the Certificate Transparency Guide.
Mis-issuance for your domain: any public CA can issue for your names unless CAA records restrict it, and attackers obtain certificates for look-alike domains (T1588.004 Obtain Capabilities: Digital Certificates). Monitor CT for your domains.
Policy you do not control: lifetimes, EKUs, validation reuse and distrust decisions are set by the Forum and root programmes. Services that cannot renew automatically become outage risks every time lifetimes shrink. See the Certificate Expiry Outages and 47-Day TLS Certificates Guide.
Over-trust for client authentication: a server that accepts any client certificate chaining to a public root accepts certificates anyone can buy. This is the reason root programmes are separating server authentication from client authentication.
Wildcards across many hosts: one public wildcard key copied to dozens of servers turns a single host compromise into an impersonation risk for the whole domain.

Threat model for private PKI

Root or issuing CA key theft: whoever holds a trusted private CA key can mint certificates for any name or identity your clients accept (T1649 Steal or Forge Authentication Certificates). Offline roots and HSM-held issuing keys are the baseline. See Securing the internal PKI and certificate authority itself.
Template and enrolment abuse: in AD CS, templates that let a requester supply the subject name can yield a certificate for a domain administrator. See the AD CS Security Guide.
Unmanaged internal CAs: a CA stood up for one project, still trusted fleet-wide years later, with no owner, logging or revocation. These are often found only during a breach.
Unconstrained trust: a private root added to every trust store can sign for public domains too, which makes it a perfect interception tool if stolen. Use name constraints on intermediates and scope trust to the clients that need it (T1557 Adversary-in-the-Middle).
Trust store drift: roots added manually to images, JVM keystores and containers are never removed, so retired or compromised CAs remain trusted. See Certificate trust stores and root CA management.

Trust distribution: the real cost of private PKI

A private CA is only useful where its root is trusted, and getting it there is most of the work. Plan the distribution channel before issuing the first certificate.

Client population	Distribution channel	Watch out for
Domain-joined Windows	Group Policy or AD publication to the enterprise trust store	Applications with their own stores (Java, Python, Node.js, browsers on some platforms)
MDM-managed laptops and phones	Trusted certificate profiles pushed by the MDM	BYOD devices outside management; profiles left after offboarding
Containers and VMs	Baked into base images or mounted at runtime from a trust bundle	Rebuild needed to remove a root; images built from public bases without your root
Kubernetes	Trust bundles distributed to namespaces, for example ClusterTrustBundles	Bundle rotation during CA changeover; workloads pinning a single root
IoT devices	Root written at manufacture; updated through signed firmware	Devices that cannot receive updates; long root lifetimes needed
Partners	Exchange of a specific intermediate or root, pinned in their configuration	No notice process for rotation; partners trusting your whole root

Two practices make trust distribution survivable. First, distribute roots, not issuing CAs, and keep root lifetimes long while issuing CA lifetimes stay moderate, so you can replace an issuing CA without touching clients. Second, keep the set of trusted roots per client as small as possible: a workload that only talks to the mesh needs the mesh root, not the corporate root. The Enterprise PKI Design and CA Hierarchy Guide covers hierarchy design.

Short-lived certificates and revocation trade-offs

Revocation is unreliable in practice, so both ecosystems are leaning on short lifetimes instead. On a private CA you can go much further than public rules allow.

Hours to days for workloads: a stolen mTLS certificate valid for 24 hours limits the attacker's window without any revocation check. The cost is that issuance becomes a dependency: if the CA or its automation is down longer than the certificate lifetime, services fail.
Weeks to a year for devices: devices sleep, roam and lose connectivity, so lifetimes must exceed the longest expected offline period, with revocation kept for lost devices.
Public TLS converges on short: with a 47-day maximum and 10-day validation reuse from 2029, public certificates will behave like short-lived ones. Anything renewed by hand will fail.
Design rule: lifetime should be at least three times the renewal interval, and renewal should start at around two thirds of life, so one failed renewal does not cause an outage.

Managed versus self-run private CA

Running your own private CA means operating root key ceremonies, HSMs, CRL and OCSP publication, audit logging and disaster recovery. Managed services take on the infrastructure, but not the policy, enrolment design or trust distribution; operating detail is in the Private CA Design and Operations Guide. Cloud services are listed alphabetically; each has its own security guide or documentation linked.

AWS Private CA: offers a general-purpose mode and a short-lived certificate mode that issues certificates with a maximum validity of seven days, intended to be deployed without a revocation mechanism and priced below general-purpose CAs; a short-lived CA must be the last CA in the hierarchy. Availability: certificates from a short-lived mode CA are issued through AWS Private CA itself rather than through AWS Certificate Manager. See the AWS Certificate Manager and Private CA Guide.
Google Cloud Certificate Authority Service: offers a DevOps tier focused on high-volume, short-lived issuance for microservices and an Enterprise tier for lower-volume, long-lived device and user certificates with listing and revocation; both tiers support HSM protection of the CA key. Availability: the tier is chosen when the CA pool is created and cannot be changed, and customer-managed CA keys through Cloud KMS are an Enterprise tier feature.
Microsoft Cloud PKI: issues device and user certificates over SCEP to Intune-managed Android, iOS/iPadOS, macOS and Windows devices, either as a cloud two-tier hierarchy or chained to an existing private CA such as AD CS (bring your own CA); licensed CAs use HSM-backed keys through Azure Managed HSM, and Intune hosts the CRL and AIA endpoints. Availability: requires a Cloud PKI subscription with Intune Plan 1 or Plan 2, allows up to three CAs per tenant, and trial CAs keep software-backed keys.

Factor	Self-run private CA	Managed private CA
Root key protection	Your HSMs, ceremonies and offline storage	Provider HSMs; you control access through cloud IAM
Main identity risk	CA server admins and template permissions	Cloud principals with issue or CA admin permissions
Customisation	Full: any profile, extension or hierarchy	Within service limits and templates
Fits	Air-gapped and OT networks, AD-integrated estates, unusual profiles	Cloud workloads, small PKI teams, MDM-driven device fleets
Exit cost	Hardware and skills	Re-issuing and redistributing trust if you migrate

Small organisations are usually best with a public CA through ACME for internet services and one managed private CA for everything else. Large organisations end up with several private CAs and need one inventory and policy across them; the Internal PKI and certificate authority health check is a useful baseline.

Where identity fits

Most private certificates are machine identities: a workload's mTLS certificate, a device certificate, a signing key held by a pipeline. They need owners, inventory and offboarding like any other non-human identity. The cloud principals that can call issuance APIs are themselves high-privilege identities, because issuance is impersonation. The GitHub code signing certificate theft showed how a compromised machine account token could reach repositories holding encrypted signing certificates, which then had to be revoked; signing keys belong in hardware or a managed signing service, not in repositories. See the Machine Identity, PKI and Certificate Lifecycle Guide.

Worked scenario: splitting a mixed estate

A retailer uses one public wildcard certificate, renewed annually by hand, for its shop, its internal admin portal, a partner order API with client certificates and internal microservices. Lifetimes drop to 200 days and Chrome's clientAuth change is coming.

Inventory: scan networks and CT logs for every certificate and key location. The wildcard key is found on 31 hosts.
Keep public where clients are public: the shop and public API move to per-service public certificates through ACME, renewed automatically.
Move internal names off public PKI: the admin portal and microservices get a managed private CA; the root is pushed through MDM and baked into base images.
Rebuild partner mTLS: issue client certificates to partners from a dedicated private intermediate and configure the API to trust only that intermediate, before public clientAuth issuance ends.
Short-lived for services: microservice certificates move to 24-hour lifetimes issued by the mesh.
Retire the wildcard: revoke it once traffic shows no remaining use, and add CAA records naming only the chosen public CA.
Rollback: keep the old chain trusted in parallel during the migration window, then remove it from trust stores on a dated plan.

Detection and measurement

CT monitoring: alert on any new public certificate for your domains, especially internal-looking names or unexpected CAs. See the Certificate Transparency Monitoring Guide for Web Teams.
CA audit logs: log every issuance, template change and CA permission change on private CAs; alert on issuance for privileged identities.
Trust store scanning: compare trusted roots on images and endpoints against the approved list.

Metric	Target
Certificates with automated renewal	Above 95%, public certificates 100%
Public certificates carrying internal-only hostnames	0
Private CAs with a named owner, inventory entry and HSM-held key	100%
mTLS client certificates issued from public hierarchies	0 before 15 March 2027
Median workload certificate lifetime	7 days or less

Common failure patterns

Public certificates for internal systems that publish the internal estate in CT and then fail when lifetimes shrink.
Client authentication built on public TLS certificates that will stop carrying the clientAuth EKU.
Shadow private CAs created for one project and trusted everywhere, with no owner.
Private roots with no name constraints trusted on every device, so a stolen key can impersonate any website.
Code signing keys in repositories or build agents rather than hardware, as in the GitHub case above.

Framework mapping

Area	NIST SP 800-53 Rev 5	NIST CSF 2.0	ATT&CK v20
Issuing and managing certificates under policy	SC-17 Public Key Infrastructure Certificates, SC-12	PR.AA-01	T1649
Certificate-based authentication of devices and workloads	IA-5(2) Public Key-based Authentication, SC-23	PR.AA-03	T1557
TLS for data in transit	SC-8	PR.DS-02	T1557
Certificate and CA inventory	CM-8 System Component Inventory	ID.AM-08	T1596.003
Code signing	SC-17, SC-12	PR.PS-01	T1553.002 Code Signing

In ISO/IEC 27001:2022 the topic sits under Annex A 8.24 Use of cryptography.

Practitioner checklist

Inventory every certificate, issuing CA and trust store, including CT results for your domains.
Classify each certificate by relying party: unmanaged clients go public, managed clients go private.
Move internal hostnames and mTLS client certificates off public CAs before March 2027.
Automate renewal for all public certificates through ACME, ready for 100-day and 47-day lifetimes.
Choose managed or self-run per private CA, with HSM-held keys and a named owner.
Apply name constraints and the smallest trust scope that works for each private root.
Set workload certificate lifetimes in hours to days and rely on expiry over revocation.
Publish CAA records and monitor CT for unexpected issuance.
Keep code signing keys in hardware and timestamp every signature.

Private PKI vs Public PKI: Which Certificates Belong on Which CA