Migrating from Public to Private CA: A Practical Playbook

1. The Deadline Made a Decision For You

Every team currently running mTLS, VPN, RADIUS, or 802.1X authentication on certificates from a public CA has the same problem to solve by the middle of 2026: those certificates will no longer be issuable. This isn't a vendor deprecation you can wait out or a roadmap slide you can ignore. It's a structural change to the public certificate ecosystem, and it arrives on a fixed calendar.

The timeline is already in motion:

The audit checklist and three migration paths (split certs vs. full private trust vs. DigiCert X9) are covered in our companion guide TLS Client Authentication Migration, and the technical reasoning behind the policy change is in Why You Can't Buy a Client Certificate from a Public CA Anymore. The short version: server authentication and client authentication have incompatible trust requirements, and the browser trust programs have decided to stop pretending they don't.

What remains is execution. The migration path is well understood, the tooling exists, and the timeline is long enough to do this without heroics – if you start now. This playbook walks through exactly what to move, how to move it, and the traps that sink most migrations.

2. Why This Is Actually an Upgrade

Public CAs were never the right home for private identity. A public certificate is a statement to the entire internet that a domain is who it claims to be, underwritten by Google, Mozilla, Apple, and Microsoft. That's a useful thing when you're terminating TLS for customers. It's an odd thing when you're authenticating a worker node to a message bus inside your own VPC.

Teams ended up using public certificates for private identity mostly because they were free, the tooling was mature, and nobody had a better answer. The cost was that every internal system inherited the policies of the public ecosystem: 47-day lifetimes, mandatory CT logging, browser-controlled algorithms, and now – starting this summer – no client authentication at all. You inherited all the constraints of public trust without gaining any of its actual benefits.

A private CA reverses that trade. You decide certificate lifetimes. You decide which algorithms to allow. You decide whether a given certificate can be used for server authentication, client authentication, code signing, or something else. You set revocation policy. You control the trust anchor. This is what public vs private trust actually means: two fundamentally different trust models, each appropriate for a different job.

The migration isn't a workaround for a public-CA change. It's a correction – moving private identity onto private trust, where it always belonged.

3. The Four Use Cases That Break

If you're using public certificates for any of the following, you're in scope for this migration. The specific breakage differs, but the fix is always the same: reissue from a private CA.

3.1 mTLS between services

Microservices authenticating to each other, service meshes running mutual TLS at the sidecar layer, APIs requiring client certificate presentation, ingress controllers validating upstream clients – any pattern where both ends of a TLS handshake present a certificate. If the client certificates come from a public CA, the server will start rejecting new issuances after June 15. Existing certificates continue to work until they expire, but under the 47-day lifetime regime that window is shrinking fast.

3.2 VPN client certificates

Corporate VPN deployments using certificate-based authentication – IPsec with certs, OpenVPN with client certs, WireGuard variants that layer on PKI – all depend on being able to issue and rotate client certificates. If your issuance pipeline pulls from a public CA (common for convenience, rare for best practice), you're about to lose that pipeline. VPN concentrators still trust the public roots, but the public roots can no longer sign anything with clientAuth.

3.3 RADIUS and 802.1X (EAP-TLS)

Wi-Fi and wired network authentication based on EAP-TLS issues certificates to every device that joins the network. Every laptop, phone, printer, and IoT endpoint holds one. When the RADIUS server validates an incoming auth request, it checks a client certificate against a trusted CA. If that CA is public, new device enrollments stop working when the public CA drops clientAuth. This is the use case where the blast radius can be the largest – a medium-sized office can have thousands of devices in scope.

3.4 Device authentication

Managed laptops authenticating to MDM, IoT fleets checking in with cloud control planes, workstations presenting a certificate to get a zero-trust access token, server-to-server attestation. These are some of the more invisible uses of client authentication – often set up years ago and quietly rotated by an automation nobody remembers owning. They're also where the first surprise outages will happen, because the failure mode is silent until a device tries to re-enroll.

4. The Migration Playbook

Six steps, in order. Each one is independent enough that different teams can own different steps, but the sequence matters – you can't cut over to a new CA that you haven't distributed, and you can't distribute a trust anchor you haven't issued.

Step 1 – Inventory every certificate doing client authentication

You cannot migrate what you cannot see. The first step is a full inventory of every certificate in your environment that has the id-kp-clientAuth EKU set, regardless of whether it's in active use. Expect surprises: a certificate issued three years ago for an integration that's now deprecated, a forgotten VPN profile on a handful of machines, a RADIUS CA that somebody stood up and left running.

Three scanning vectors together give you coverage: Certificate Transparency logs for anything ever issued publicly under your domains; network scans for anything serving TLS today; and filesystem or secrets-store scans for certificates that live in configuration files, Kubernetes secrets, or vault paths but never appear on the wire. [cyphrs] Scout runs all three and flags clientAuth EKUs explicitly, but the principle applies whatever tool you use – one scan vector always misses something.

The output of this step is a concrete list: every certificate, its expiry, its issuer, the system that depends on it, and the owner. Everything downstream is triaged from that list.

Step 2 – Choose your private CA architecture

Three architectural decisions to make before you issue the first certificate:

Root and intermediate structure. An offline root with one or more online intermediates is the standard pattern. The root signs only the intermediates and lives offline. The intermediates do the day-to-day issuance. Reasonable intermediate lifetimes are 5–10 years; reasonable leaf lifetimes for client authentication are 30–180 days depending on how automated your rotation is.

Algorithms. ECDSA P-256 or P-384 for classical use, plus an embedded ML-DSA signature for post-quantum readiness if your CA supports it. RSA still works everywhere, but new roots built in 2026 should plan for the quantum transition rather than against it. See Post-Quantum Cryptography Is Not a Future Problem for the longer argument.

Deployment topology. On-premises, cloud, or hosted. On-premises keeps the keys inside your network perimeter and is the right answer for anything sensitive. Cloud-hosted private CAs (AWS Private CA, Google CAS) are quick to stand up but tie your trust anchor to a specific cloud. The lighter-weight modern option is a containerised CA you run yourself – [cyphrs] Trust CA deploys in roughly 30 minutes via Docker Compose and issues both server and client certificates from the same infrastructure.

Step 3 – Distribute the trust anchor

This is the step most migrations underestimate, and it's the one that causes the largest outages when it goes wrong. Before a single client certificate from your new CA is useful, every system that needs to verify those certificates must trust the new root. That's the relying party problem, and it's entirely a distribution problem.

Distribution paths depend on the relying party:

The sequencing matters: push the new root to every relying party before issuing any leaf certificates from it. Verify distribution completed. Only then does anything start using the new chain.

Step 4 – Issue new certificates through the right protocol

Match the enrollment protocol to the relying population. The goal is always to end up with automated issuance, because anything manual won't survive contact with a 47-day lifetime.

ACME for anything Linux-native or containerised, including workload identity for microservices and ingress. The same protocol Let's Encrypt uses works equally well against a private CA, and it's the most well-supported client ecosystem. A private CA that speaks ACME means every existing Certbot, cert-manager, or acme.sh deployment can repoint at it with a configuration change.

SCEP and EST for device enrollment where the client is a laptop, phone, or network appliance. MDM platforms, 802.1X supplicants, and most VPN clients speak SCEP natively. EST is the modernised equivalent and is what you want for anything built this decade.

Direct API for anything exotic – custom workloads, service meshes with their own SPIFFE/SPIRE identity plane, or CI pipelines that mint short-lived build certificates. A REST API that takes a CSR and returns a certificate covers the cases the standard protocols miss.

Whatever the protocol, the profile should be tight: clientAuth EKU only (not dual-purpose), the minimum key usage flags, and a subject that encodes the workload identity rather than a hostname. Certificates for service mesh workloads follow SPIFFE URI SANs. Certificates for devices encode a device ID. Certificates for people encode a user identifier. Don't carry over the public-CA habit of cramming everything into the Common Name.

Step 5 – Cut over the authentication pipelines

With the new root trusted and new leaf certificates being issued, the actual cutover is a configuration change on the validating side: update the trusted issuer list on your RADIUS server, your VPN concentrator, your mTLS ingress, your API gateway. In most systems this is a matter of pointing the ca-bundle at the new chain.

Do this in overlap mode wherever possible. Configure the validator to trust both the old public chain and the new private chain simultaneously, then let the client population migrate over the natural renewal cycle. For 47-day certificates that's one or two months of overlap. For 90-day device certificates, roughly a quarter. A hard cutover – flipping every client at once – is almost always the wrong answer unless the population is small enough to coordinate manually.

Monitoring during overlap is the key signal: every authentication event should be tagged with which issuer chain verified it, and the ratio of old-to-new should move monotonically toward new over the overlap window. If it doesn't, something isn't renewing, and you want to find it before the old chain expires – not after.

Step 6 – Revoke, verify, and document

Once the new chain carries the full traffic, the old public client certificates should be revoked and removed from trust bundles – first to close out any stragglers still using them, and then to tighten the validator configuration so that only the new chain is accepted. Leaving the old chain trusted indefinitely defeats the security benefit of the migration.

Verification is straightforward: re-run Step 1's inventory and confirm zero public certificates with clientAuth EKU remain in service. Document what you built – the root topology, the enrollment protocols, the distribution paths, the revocation procedure. This documentation is what makes the migration durable. The next policy change from Chrome, Google, or the CA/Browser Forum will be easier to absorb because the private trust layer is already under your control.

5. Common Migration Traps

Five patterns show up repeatedly when migrations go sideways. Most are avoidable if they're on your radar from day one.

6. The Migration Checklist

A compact version of the playbook for your planning doc:

7. This Is Trust, Not Just Certificates

The instinct during a forced migration is to do the minimum: move the affected certificates, keep everything else the same, tick the box, move on. That instinct misses the opportunity.

Every team running private identity on public certificates was, in effect, renting their trust from the public CA ecosystem. The Chrome change is what renting looks like: the landlord changes the terms and you move. A private CA is ownership – the same infrastructure that issues your mTLS certificates today can issue certificates for AI agents tomorrow, can adopt post-quantum algorithms on your timeline rather than someone else's, and doesn't depend on a browser trust program deciding what private identity is allowed to look like.

The migration playbook above also happens to be the foundation for the next two shifts already visible on the horizon: agent-to-agent identity, which will multiply the number of non-human certificate-bearing workloads by an order of magnitude, and post-quantum cryptography, which will require every root in active use to carry quantum-safe material. A team that finishes this migration in 2026 with a modern private CA has already done most of the work for both.

The June 15 deadline is a forcing function. The migration itself is a correction that should have happened anyway.