Blog

With all the conflicts happening around the world, the last thing an IT admin expects is "friendly fire" between their web browser and the collaboration servers they manage. But big changes are coming to Google Chrome and they’re coming fast.If you manage Cisco Collaboration, the "standard" way you’ve handled certificates for the last decade is about to break. Here’s what you need to know to keep the lights on.

What is Chrome actually doing?

Google is fundamentally changing how it treats Public Certificate Authorities (CAs). There are three major "shocks" to the system:

1. Banning “Dual-Use” Certificates: Starting June 15, 2026, Public CAs can no longer issue certificates that support both Server and Client Authentication. It’s one or the other.
   
   
2. Dedicated TLS Roots: Chrome is forcing CAs to use roots dedicated exclusively to web traffic.
   
   
3. The "Incredible Shrinking" Certificate: Validity is dropping from 398 days to 200 days, with a final goal of just 47 days. If you aren't automating, you're going to be very busy renewing certs.

Why Chrome Policies are Redefining Public Trust

To understand why Google Chrome’s recent policy shifts are so impactful, we must first examine the fundamental role of a Public Certificate Authority (CA).

Originally, Public CAs were established to solve a single, critical problem: Authenticating websites for the general public. When a user navigates to a sensitive domain, such as webex.com , through a browser, they need a guarantee that they are communicating with the legitimate service rather than a malicious interceptor. Chrome facilitates this trust by validating the website's digital certificate against its internal Root Store.

The Mechanics of Browser Trust

Chrome is shipped with a pre-vetted list of "Trusted Roots." For a CA like DigiCert, Sectigo, or IdenTrust to remain on this list, they must strictly adhere to the Chrome Root Program Policy. This is not a formal government regulation, but a technical requirement for market viability; if a CA fails to comply, Chrome will revoke its trust.

For the end-user, a "distrusted" CA results in a "Your connection is not private" warning page. For an organization, it means a total loss of accessibility for customers and employees.

The Shift Toward "Purpose-Driven" PKI

Historically, the industry has treated certificates as "all-purpose" tools. However, Google is now enforcing a strict separation of concerns. Chrome’s vision is that Public CAs should exist exclusively for public website identity (Server Authentication).

By June 2026, Chrome will no longer trust public certificates that attempt to handle both server and client authentication. This shift is designed to reduce the "blast radius" of a potential CA compromise and force internal application-to-application security into more appropriate, private environments.

What is Chrome trying to achieve through those Changes?

1. Banning the “Dual-Use” Certificates
   1.    Chrome is trying to move the industry toward a Zero Trust architecture where a single       digital identity cannot be repurposed for different types of access.
   2.    Reduction of the Attack Surface:
      1.       By stripping the Client Authentication usage from Public website certificates, Google          ensures that a compromised web server certificate is useless for penetrating deeper        into an Org’s infrastructure.
   3.    Public CAs were designed to tell a browser: “this is definitely Webex.com”. They were         never meant to be used to internal device-to-device authentication.
      1.        Chrome is forcing a clean break between Public Trusts (the Open Internet) and                    Private Trust ( internal Cisco Clusters).
         
         
2. Dedicated TLS Roots
   1.    When a Root CA is “Multi-Purpose,” it is extremely difficult for browsers to audit them.     A CA might be doing a great job validating website owners but a terrible job validating         VPN users.
   2.    By requiring dedicated TLS roots, Chrome can audit CAs with 100% focus on website         security.
   3.    If a CA want to issue client certificates for Cisco MRA or VPNS, they must do so from a       completely different root that Chrome doesn’t even have to look at it.
   
   
   
3. Lifetime Reduction
   1.    Lifetime reduction shortens the Window of Vulnerability.
   2.    If a private key is stolen or a certificate is mis-issued today, an attacker can                         theoretically use for over a year (398 days).
   3.    By shortening the lifespan, Chrome ensures that a compromised certificate becomes         useless much faster.
   4.    At a 47 day limit, a stolen key has a very short “shelf life” becomes the browser                   automatically rejects it.
   5.    By making the renewal cycle so short (8 times a year), Chrome makes manual                       management impossible. This forces Orgs to adopt automated tools like ACME.
   6.    The math that secures today’s internet (RSA and ECC) will eventually be breakable by          quantum computers. To survive the entire internet will need to switch to new                      “Quantum-Resistant” algorithms quickly. If certs last a year, that transition takes                forever. If they last 47 days the entire world can be upgraded to new security                      standards in less than 2 months.

What do Cisco Admins need to do?

Many on Premises communications products and deployments have been designed around a single certificate being reused across multiple roles:

1. Acting as a server for admin/UI access and inbound TLS connections.
   
   
2. Acting as a client when initiating outbound TLS connections to Peers( for example trunks, federations and integrations)

Now that Chrome will be rejecting certs that contain both Server and Client certificates, its imperative to do the following steps:

1. Which systems are using Public CA-Issued certificates.
   
   
2. Which certificates currently have both server auth and client auth EKUs?
   
   
3. Which certificates require mutual TLS (mTLS) or client certificate authentication?
   
   
4. What are the expiration dates and renewal windows?

Cisco On premises calling products can be affected by potential authentication issues and impacted functionality due to broken certificate validity that is caused by using Server-Authentication only certs provided by Public Root CAs.

The following list shows examples of certificates that are used for mTLS connections in these Cisco on premises calling products:

1. Cisco Call Manager/SME
   1.    Tomcat, TVS, Call Manager, IPSec
      
      
2. Cisco IM&P
   1.    CUP-XMPP-S2S
      
      
3. Cisco Unity Connection
   1.    Tomcat
      
      
4. Cisco Emergency Responder
   1.    Tomcat.

The following are examples of certificates that are used for different mTLS connections:

1. Tomcat: Connections with External Servers like LDAP, filebeat, logslash server, and SIP OAuth over MRA
   
   
2. Call Manager: SIP Trunk connections and internode, inter-cluster nodes.
   
   
3. TVS: Online-CAPF connection.
   
   
4. IPSec: IPSec connections with other CUCM and third party clusters.
   
   
5. CUP: Secure SIP connections with CUCM and 3^rd party clients.
   
   
6. CUP-XMP-S2S: Extensible Messaging and Presence Protocol federation.

Interim Solutions

Option 1: Switch to Public Root CAs that provide combined EKU certificates

There are still Public CAs out there that can still issue Web Server + Client certificates, (DigiCert and IdenTrust) from an alternate root which will not be included in the Chrome browser’s trust store.

This approach alleviates the need to upgrade server software to mitigate sunsetting of Client Authentication EKU enforced by the Google Chrome Root Program Policy.

Downside is you will get a warning of website not trusted before logging into it.

Option 2: Switch to Private CA Roots

If you do move to a Private Root CA, you will have the ability to generate Web Server and Client certificates for dual use and maintain service operations.

Same downside as option 1, you will get a warning of website not trusted before logging in.

Cisco Expressway Fix

Cisco Expressway is probably the most vulnerable to this change. They require a Web server and client certificate because Expressway nodes need to authenticate themselves to each other and to other Collaboration nodes.

Also, they need to authenticate remote clients that are attempting to register to On Prem Call Manager.

Cisco released Expressway x15.4 which includes a commands that will allow admins to upload Server Only EKU certificates and it uses this Server only certificate to maintain services.

The command is: xConfiguration XCP TLS Certificate CVS EnableServerEkuUpload: On

Long-Term Solutions

Moving forward, Cisco will be segregating certificates. There will be a TOMCAT Server Certificate and a Tomcat Client certificate, and admins will need to renew both or upload both or have a self-signed cert for both.

Future releases by Cisco will include this segregation.

When you upgrade, your Tomcat Cert will be copied once into the Tomcat Server Certificate and once into the Client Server certificate.

If you need any assistance staying in operation during these certificate turbulence times, feel free to reach to us at LookingPoint, please reach out to us at sales@lookingpoint.com and we’ll be happy to help!