Cisco Warns TLS Certificate Changes Could Break mTLS

Organizations relying on mutual TLS authentication need to audit their certificate infrastructure now. Starting June 2026, public certificate authorities will stop issuing TLS certificates that include the clientAuth Extended Key Usage attribute, breaking workflows that depend on dual-purpose certificates.

Cisco published guidance this week explaining how the industry-wide shift affects its products and what customers must do to avoid service disruptions. The changes stem from Google Chrome's updated root program requirements, which mandate separating server and client authentication into distinct certificate types.

What's Actually Changing

The CA/Browser Forum baseline requirements now prohibit public certificate authorities from including both serverAuth and clientAuth EKUs in the same certificate. This matters because mutual TLS (mTLS)—where both client and server authenticate each other—typically relies on certificates containing both attributes.

Let's Encrypt announced its timeline last year: the default profile removes clientAuth on February 11, 2026, with complete removal by May 13, 2026. DigiCert eliminated clientAuth from default certificate orders in October 2025 and will stop issuing it entirely by May 2026.

Existing certificates issued before these deadlines remain valid until they expire. But the clock is ticking for organizations that haven't planned their migration.

Which Cisco Products Are Affected

Cisco's Field Notice FN74350 details the impact on Unified Border Element (CUBE) deployments running IOS XE 16.x and 17.x. The notice also flags Expressway servers and Cisco Calling on-premises products as affected.

CUBE in particular presents a challenge. The platform uses mTLS for SIP trunk connections, and certificates must contain both EKU types for mutual authentication to work. Without the clientAuth attribute, one side of the TLS handshake fails validation.

"Cisco's ecosystem has different security requirements which include trusting root certificates for its services and equipment to securely authenticate both clients and servers," the company noted in its blog post.

ISR 4000 Series platforms won't receive the fix that allows certificate segregation, adding urgency for organizations running that hardware.

Critical Deadlines

Organizations should mark these dates:

• March 15, 2026: Last recommended date to renew combined-EKU certificates before the 200-day validity limit takes effect
• May 2026: Public CAs stop issuing certificates with clientAuth EKU
• June 15, 2026: Chrome Root Program Policy enforces the restriction

Certificates obtained before these cutoffs will honor their full validity period. Renewing now buys time to implement a longer-term solution.

Three Paths Forward

Cisco outlines several workarounds depending on your deployment:

Switch to alternative CAs: Some public CAs, including DigiCert and IdenTrust, issue combined-EKU certificates from alternative roots that aren't part of Chrome's trust store. These work for server-to-server mTLS but won't validate in browsers. Cisco recommends adding IdenTrust Public Sector Root CA 1 and DigiCert Assured ID Root G2 to trust stores.

Deploy private PKI: The restrictions apply only to public CAs. Organizations running their own certificate authority can continue issuing combined-EKU certificates indefinitely. This approach works well for internal systems that don't need public trust.

Upgrade and segregate: Cisco plans to release IOS XE 26.1.1 with support for certificate segregation—separate certificates for server and client authentication on the same interface. This lets organizations use public CA certificates for server auth while maintaining private CA certificates for client auth.

Wider Enterprise Impact

The certificate changes extend beyond Cisco products. Any system using public TLS certificates for mTLS faces the same constraints. VPN gateways relying on certificate-based user authentication, API endpoints using mutual TLS, and IoT deployments with certificate-pinned devices all need evaluation.

This shift connects to broader changes in certificate management. We covered CISA's new edge device requirements that push federal agencies toward modern infrastructure—infrastructure that increasingly depends on properly configured PKI.

Organizations using VPNs for remote access will feel this acutely. Certificates lacking the clientAuth EKU simply won't authenticate users to VPN gateways after the transition. Remote workers could lose access if IT teams don't migrate before the deadline.

Steps to Take Now

Cisco recommends starting with an inventory. Identify every public TLS certificate in use and check which ones contain the clientAuth EKU. Certificates for internal systems should move to private PKI, while external-facing services may need the alternative CA approach.

Test thoroughly before production deployment. The Cisco documentation on Expressway certificates provides specific guidance for unified communications deployments.

For organizations running Cisco infrastructure, the post-quantum cryptography guidance Cisco published earlier this year offers a useful framework for thinking about long-term certificate strategy. Both initiatives require auditing existing PKI deployments and planning gradual migrations.

The four-month window before the first major deadline leaves enough time for planning—but not procrastination. Organizations that wait until May will find themselves rushing through certificate changes with production systems at risk.