mTLS vs Private PKI: Which to Use After Public CA Deprecation

After public CAs began deprecating internal-name SANs and shortened certificate validity to 47 days under the CA/Browser Forum ballot SC-081, organizations relying on public certificates for internal services face a clear choice: adopt mutual TLS authentication backed by a private CA, or build a full private PKI to replace public CA dependency entirely. The answer depends on scope. mTLS solves the authentication problem for service-to-service communication. Private PKI solves the issuance problem - who signs the certificates mTLS needs to function. Most mature zero-trust environments require both.

Why Does Public CA Deprecation Force This Decision?

Public CAs under CA/Browser Forum rules have always prohibited issuing certificates to internal hostnames like app.internal or db.prod. The 2025–2026 push to 47-day maximum validity under the CA/Browser Forum Baseline Requirements (updated March 2026) makes manual renewal for hundreds of internal services operationally impossible.

So teams that previously used public DV certificates for internal APIs, service meshes, or IoT device authentication now need an alternative trust anchor. Private PKI fills that gap directly. mTLS is the enforcement layer that sits on top.

What Does mTLS Actually Do - and What Does It Not Handle?

mTLS extends standard TLS by requiring the client to present a certificate, not just the server. Per RFC 8446 (TLS 1.3), this uses the CertificateRequest and Certificate handshake messages in both directions. The result is cryptographically verified identity on both ends - no API keys, no passwords, no session tokens.

But mTLS does not issue certificates. It relies entirely on a pre-existing trust chain. Every mTLS deployment needs a CA - either a public CA (now increasingly restricted for internal use) or a private one. Without public key infrastructure underneath it, mTLS has nothing to validate against. So the question is never "mTLS or private PKI" as if they compete - it's whether your PKI needs to be private.

mTLS vs Private PKI: Side-by-Side Comparison

How Do You Choose Between mTLS Alone vs. Private PKI?

The scale of your internal certificate estate is the deciding variable. If your organization manages fewer than 50 internal TLS endpoints and uses a service mesh like Istio that auto-provisions certificates via SPIFFE/SVID, a lightweight private CA (HashiCorp Vault PKI, cert-manager with an internal root) is sufficient. mTLS handles enforcement; the embedded CA handles issuance.

At 500+ internal services, IoT device fleets, or multi-cloud environments spanning AWS, GCP, and Azure - a standalone private PKI with a hardware-backed root CA and an ACME-capable intermediate is the correct architecture. The root CA vs intermediate CA split matters here: the root CA stays offline (air-gapped or HSM-protected), while the intermediate CA handles day-to-day issuance.

What Is the Correct Deployment Path After Public CA Deprecation?

1. 1
   Audit all certificates - identify every internal hostname, service, and device currently using a public CA certificate. Tools like Venafi or open-source certbot --dry-run scans surface this inventory in under an hour for most environments.
2. 2
   Stand up a private root CA - generate a 4096-bit RSA or P-384 ECDSA root CA key, store it in a FIPS 140-2 HSM (AWS CloudHSM, Azure Dedicated HSM, or a physical YubiHSM 2), and keep it offline. The root certificate validity should be 10–20 years per NIST SP 800-57 Part 1 Rev. 5 guidance.
3. 3
   Create an issuing intermediate CA - set validity to 2–5 years. This CA handles all ACME, SCEP, or EST protocol requests from internal services. Limit its name constraints to your internal DNS zones (e.g., .corp, .internal).
4. 4
   Configure mTLS enforcement - update your service mesh, API gateway (Kong, Envoy, NGINX), or application code to require client certificates signed by your private intermediate CA. Verify TLS 1.2 vs TLS 1.3 compatibility across services before enforcing.
5. 5
   Automate certificate rotation - with 47-day lifetimes becoming standard, manual renewal is not viable. Deploy cert-manager (Kubernetes), ACME clients (acme.sh, Certbot), or an enterprise ACME server (Smallstep CA, EJBCA) to automate issuance and renewal against your private CA.
6. 6
   Publish a CRL or OCSP responder - revocation is non-optional for compliance. Publish your CRL endpoint in the CDP extension of every issued certificate. For low-latency environments, an OCSP stapling-capable responder eliminates round-trip latency during TLS handshakes.

What Are the Certificate Requirements for mTLS Clients?

Client certificates for mTLS must carry the Extended Key Usage (EKU) value of Client Authentication (OID 1.3.6.1.5.5.7.3.2). Without this OID, TLS stacks like OpenSSL 3.x and BoringSSL will reject the certificate during the handshake, even if it is otherwise valid. Review your client certificate requirements against this OID before deployment.

Per CA/B Forum BR Section 7.1.2.7.4, client certificates issued under a publicly-trusted CA must also not contain internal IP addresses or reserved DNS names in the Subject Alternative Name. Private PKI has no such restriction - which is exactly why it is the correct tool for internal service authentication after public CA deprecation.

How Does mTLS Fit Into a Zero-Trust Architecture?

NIST SP 800-207 (Zero Trust Architecture) identifies certificate-based mutual authentication as a Tier 3 identity assertion - the strongest non-biometric form. mTLS over a private PKI satisfies this requirement for workload identity. The SPIFFE/SPIRE standard (adopted by CNCF in 2020) formalizes this: each workload receives a SPIFFE Verifiable Identity Document (SVID) - an X.509 certificate issued by an internal CA - and presents it via mTLS to authenticate to other workloads.

Platforms that implement SPIFFE natively include Istio (since v1.5), HashiCorp Consul Connect, and AWS App Mesh. Each uses a short-lived private CA under the hood, confirming that private PKI is not optional in zero-trust deployments - it is load-bearing infrastructure.

Frequently Asked Questions

Can I use a public CA certificate for mTLS after the 2026 deprecation changes?

For external-facing APIs where both parties are internet-connected organizations, public CA certificates remain valid for mTLS. But for internal services, microservices, or IoT devices using internal hostnames, public CAs cannot issue the necessary certificates. Private PKI is required in those cases.

Is a private PKI the same as a self-signed certificate?

No. A private PKI uses a proper CA hierarchy - root CA and intermediate CA - with defined policies, CRL/OCSP revocation, and automated issuance. Self-signed certificates have no issuing CA and cannot be centrally revoked. Self-signed certificates are not suitable for mTLS at scale because there is no shared trust anchor across services. Per certificate authority definitions, a CA - even a private one - provides the chain of trust that mTLS requires.

What is the recommended certificate validity for mTLS certificates in a private PKI?

NIST SP 800-57 Part 1 Rev. 5 recommends short lifetimes for machine identity certificates. In practice, 24–90 days is standard for service certificates in automated environments. With ACME-based automation, 24-hour certificates are operationally viable and reduce the window of exposure from a compromised key to a single day.

Does mTLS replace API keys or OAuth tokens?

mTLS replaces the need for shared-secret credentials (API keys, passwords) at the transport layer. It does not replace application-layer authorization (OAuth 2.0, JWT). A best-practice zero-trust architecture uses mTLS for transport-level mutual authentication and a token-based system (OAuth 2.0 with mTLS sender-constrained tokens per RFC 8705) for fine-grained authorization.

Which tools automate certificate issuance for private PKI + mTLS?

The leading open-source options are cert-manager (Kubernetes-native, supports ACME and internal CAs), Smallstep CA (purpose-built for internal mTLS with ACME and SPIFFE support), and HashiCorp Vault PKI Secrets Engine. Commercial options include Venafi TLS Protect, AppViewX CERT+, and AWS Private CA. The right choice depends on your orchestration platform and compliance requirements.

Is a hardware security module (HSM) required for a private PKI root CA?

HSMs are not legally required but are mandated by most compliance frameworks. SOC 2 Type II, FedRAMP, and PCI-DSS all require CA private keys to be protected in FIPS 140-2 Level 2 or higher hardware. For any private PKI intended to satisfy audit requirements, an HSM for the root CA key is non-negotiable. Offline software keys are acceptable only for lab or development environments.

The Right Answer Depends on Scope - Not Preference

After public CA deprecation of internal-name certificates and 47-day validity mandates, the question is not whether to adopt private PKI - it is how quickly and at what scale. mTLS solves authentication. Private PKI solves the trust anchor problem that mTLS depends on. Use mTLS at every internal service boundary. Use private PKI to sign every certificate mTLS requires. For organizations starting from zero, a managed private CA service (AWS Private CA at $400/month, or Smallstep Teams) gets you operational in under a day with full automation and ACME support.

Key insight: The teams that struggle after public CA deprecation are those who treat it as a certificate problem. It is an infrastructure problem. Building private PKI now - before a CA distrust event forces an emergency migration - is the only risk-appropriate response.