Starting in mid-2026, public Certificate Authorities will no longer issue TLS certificates containing the Client Authentication Extended Key Usage (clientAuth EKU). This post breaks down why this change is happening and provides a practical roadmap for migrating to a private CA.
The CA/Browser Forum and Google's Chrome Root Program have mandated that publicly trusted CAs stop issuing TLS certificates with the clientAuth EKU. The key dates:
After these deadlines, new public TLS certificates will only contain the serverAuth EKU. Existing certificates will work until expiration, but renewals will not include client authentication capabilities.
This policy shift addresses fundamental security and architectural concerns:
Public trust has a specific scope. Public CAs exist to establish trust on the public internet, primarily for authenticating websites to browsers. Client authentication is typically an internal matter where organizations authenticate their own users, devices, and services. Mixing these use cases under the same trust hierarchy created unnecessary complexity.
Dedicated hierarchies improve security. By requiring server-authentication-only hierarchies, the Chrome Root Program enforces clearer boundaries. This makes certificate policies easier to audit and aligns public PKI with its original intent: securing public web traffic.
The bottom line: Client authentication belongs in private PKI, where you control the trust anchor, issuance policies, and lifecycle.
The migration requires careful planning. Here's a practical roadmap:
Before you can migrate, you need complete visibility into your certificate landscape.
What you need to identify:
The challenge: Most organizations lack complete visibility. Certificates are scattered across servers, load balancers, containers, cloud services, IoT devices, and end-user machines. Manual discovery is time-consuming and inevitably incomplete.
How Itva solves this: Itva is the only tool on the market that can automatically discover and inventory all your active certificates across your entire infrastructure, including on-premises, cloud, hybrid, and edge environments. Itva scans your network, integrates with your infrastructure components, and builds a comprehensive Cryptographic Bill of Materials (CBOM).
More importantly, Itva identifies exactly which certificates are using client authentication and maps them to the specific applications and services that depend on them. This gives you a clear picture of your exposure and a prioritized migration list.
Once you understand your certificate inventory, you need to establish a private PKI infrastructure. For organizations with existing Windows infrastructure, Active Directory Certificate Services (ADCS) provides a straightforward path, but any private CA solution that fits your environment will work.
Key considerations when setting up your internal CA:
This is where many migration efforts fail. Even after setting up a private CA, organizations try to manage certificates manually. This approach is:
The average enterprise manages thousands of certificates. With shorter validity periods becoming standard, manual management simply isn't sustainable.
How Itva transforms certificate lifecycle management:
Itva doesn't just discover your certificates. It automates the entire lifecycle from request to retirement:
With Itva, migrating from public CA client certificates to private CA certificates becomes a managed process. Itva orchestrates the transition, tracking which certificates have been migrated, which are pending, and ensuring no application is left behind.
Ready to get started? Contact Itva to begin your certificate discovery and migration planning.
