Skip to main content
PKI

Navigating the Upcoming TLS Client Authentication Requirements

The TLS landscape is changing, and organizations need to prepare. The CA/Browser Forum has approved new requirements that will significantly impact how client authentication certificates are managed. Here's what you need to know and how to prepare.

Quick Recap: What's Changing

The CA/Browser Forum has voted to limit the use of publicly trusted certificates for client authentication. Key dates to remember:

  • April 2025: New TLS Baseline Requirements take effect
  • April 2026: Public CAs must stop issuing certificates with the clientAuth Extended Key Usage (EKU)
  • April 2029: All existing publicly trusted certificates with clientAuth EKU expire or are revoked

This means organizations currently relying on public CAs for client authentication certificates will need to transition to private or internal Certificate Authorities.

Why This Change?

The rationale behind this policy change centers on several important factors:

  • Security Improvement: Public CAs were never designed to handle the nuanced trust decisions required for client authentication. Moving to internal CAs gives organizations more control over their trust boundaries.
  • Compliance Alignment: The change helps align TLS practices with industry standards and regulatory requirements.
  • Reduced Attack Surface: By separating client authentication from public trust hierarchies, the overall attack surface is reduced.

Steps to Migrating to an Internal CA

Step 1: Audit Your Current Certificate Landscape

Before you can plan a migration, you need to understand what you're working with. This means inventorying all certificates across your infrastructure that use the clientAuth EKU.

Key questions to answer:

  • How many certificates use clientAuth?
  • Which systems and services depend on these certificates?
  • What are the expiration dates?
  • Which CA issued them?

This is where tools like ITVA become invaluable. ITVA can automatically discover and inventory all certificates across your network, giving you complete visibility into your certificate landscape.

Step 2: Plan Your Internal CA Infrastructure

Once you understand your current state, you need to plan your internal CA deployment:

  • Choose your CA platform: Options include Microsoft AD CS, EJBCA, HashiCorp Vault, or other PKI solutions
  • Design your hierarchy: Determine the appropriate CA hierarchy (root, intermediate, issuing CAs)
  • Define certificate policies: Establish templates, validity periods, and key usage constraints
  • Plan for automation: Manual certificate management at scale is unsustainable — plan for automated issuance and renewal from the start

Step 3: Execute the Migration

With your plan in place, begin the phased migration:

  1. Deploy your internal CA infrastructure in a staging environment first
  2. Issue new certificates from your internal CA for a subset of services
  3. Update trust stores on systems that need to validate these certificates
  4. Monitor and validate that services continue to function correctly
  5. Gradually expand the migration to cover all affected services
  6. Decommission public CA dependencies for client authentication

Next Steps

The clock is ticking on this migration. Organizations that start planning now will have a smoother transition than those that wait until the deadlines are imminent.

Need help getting visibility into your certificate landscape? ITVA provides automated certificate discovery and lifecycle management that makes migrations like this manageable. Get in touch to learn how we can help you prepare for these changes.