Google Chrome is enforcing a new root program policy that changes what it will accept in publicly trusted TLS certificates. If you run on-premises calling and collaboration infrastructure like Cisco UCM, Expressway, CUBE, IM&P, Unity Connection, CMS, etc., this policy shift can cause unexpected outages unless you take action.
Key Takeaways:
- What’s Changing: Google Chrome is enforcing a new policy that drives public Certificate Authorities (CAs) to stop issuing dual‑use (server+client EKU) certificates for servers. This is an industry-level event that is outside of Cisco’s control.
- Impact: Without action, some Cisco on-premises collaboration/calling applications may stop working by May, 2026 (or sooner at your next cert renewal/auto‑renewal).
- What’s Impacted: All Cisco on-premises applications, including CUCM / SME, IM&P, CUCe, CER, Expressway, CUBE, and others. As this is an industry-level event, you should evaluate the potential impact to all network-based applications.
- First Step: Inventory all certificates—identify public CA certs, combined EKU usage, and any mTLS/client‑auth dependencies.
- Preferred Remediation: Work with your CA to use an alternate chain/route that still supports server+client EKU for non‑browser peer connections, or switch providers if required.
- Stopgap: If you can’t switch quickly, renew early (before your CA’s cutoff) to buy time—certificate lifetimes are shrinking, so this is temporary.
- Long term: Adopt product updates that separate server and client certificates to eliminate reliance on dual‑use certs.
- Review: Field Notices – FN74345: UCM/SME/IM&P/CUC/CER, FN74362: Expressway, FN74350: CUBE
- If you have questions contact: ask-collaboration-eku@external.cisco.com
Overview
Digital certificates help systems prove identity and establish encrypted connections. A key part of a certificate is Extended Key Usage (EKU), which indicates what the certificate is allowed to be used for—most commonly:
- Server Authentication (a system proving it’s the server)
- Client Authentication (a system proving it’s an authorized client)
Historically, many public Certificate Authorities (CAs) issued certificates that included both server and client authentication EKUs by default (often called a “dual” or “combined EKU” certificate).
According to Chrome’s updated policy, when Chrome connects to a server, that server’s certificate must not include the Client Authentication EKU. If it does, Chrome may treat it as untrustworthy. Chrome is also using its root program leverage to push CAs to stop issuing these combined EKU certs on their publicly trusted chains.
This is an evolving industry change that may expand to other browsers.
Impact to Cisco Collaboration Applications
Many on-premises communications products and deployments have been designed around a single certificate being reused across multiple roles:
- Acting as a server for admin/UI access and inbound TLS connections
- Acting as a client when initiating outbound TLS connections to peers (for example trunks, federation, integrations)
To simplify operations, environments often rely on one certificate that covers both roles. As CAs move to issuing server-only certificates by default, deployments that expect a combined EKU may break in the “client auth” direction—because the new cert no longer includes the client authentication EKU that some workflows assume.
Separately, where browsers are involved, a “server cert that also claims client auth” becomes increasingly problematic under Chrome’s enforcement.
Key Milestones
There are two overlapping timing pressures:
1) Chrome enforcement (June 15, 2026)
Chrome plans to enforce this policy starting on June 15, 2026, which drives CA behavior.
2) CA issuance behavior changes (often May 2026, but varies)
Many CAs are planning to stop issuing combined EKU certificates (or stop doing so by default) before the Chrome enforcement date—often around May 2026—to avoid being removed from Chrome’s trust store.
Important: Timelines can differ by CA vendor and even by specific CA “root” or “intermediate” chain used.
Important Consideration: Renewal can unintentionally break existing functionality
A common failure scenario looks like this:
- Your environment has been working with a combined EKU cert.
- You renew a certificate through your CA portal (often “business as usual”).
- The CA issues a server-only certificate (because policy changed).
- You install it—and something that depends on client authentication EKU (or a dual-use assumption) fails.
This is why inventory + planning matters, even if your current certs still work.
Impact to Cisco Expressway
Expressway has a special risk case in environments using Let’s Encrypt with automated renewal. Let’s Encrypt certificates are short-lived (commonly 90 days), and the automation means a renewal can pull in a server-only certificate from Feb 11, 2026 without anyone noticing—potentially triggering breakage quickly when the issuing profile changes.
If you rely on automated public cert renewal, review this immediately.
Actions to Take Now
1) Inventory and Audit Certificates
Start with an audit across your environment:
- Which systems use public CA-issued certificates?
- Which certificates currently have both server auth and client auth EKUs?
- Which connections require mutual TLS (mTLS) or client certificate authentication?
- What are the expiration dates and renewal windows?
This gives you a prioritized list of what is at risk and when.
2) Preferred Path: Use a CA Option That Still Supports Combined EKU (via an Alternate Chain/Route)
Some CA providers have (or are introducing) alternate issuance chains:
- One chain that remains Chrome-trusted and issues server-only
- Another chain that can continue to issue server+client EKU for non-browser peer-to-peer use cases (but may not be Chrome-trusted)
If your CA offers an alternate route that still issues combined EKU certificates for your use case, moving to that route is often the least disruptive option—your apps and workflows can remain largely unchanged. If your CA doesn’t offer that option, you may need to switch providers.
This is the most immediate option that eliminates the need immediately upgrade your applications.
3) Short-term stopgap: renew early (buy time)
If you can’t switch CA/provider quickly, renewing your certificate before your CA stops issuing combined EKU may buy you runway—because certificates issued before the cutoff can remain valid through their normal term.
Also note: the industry is reducing certificate lifetimes (for example, moving from ~398 days down to ~200 days and potentially shorter over time). That means renewal cadence increases, and “buying time” may be measured in months, not years.
4) Alternative for some environments: private CA / self-signed (where feasible)
In certain peer-to-peer or controlled enterprise contexts, using a private PKI (enterprise CA) or self-signed certificates can be viable. Whether this works depends on the endpoints/peers you must interoperate with and their trust requirements.
5) Product direction: separating server and client certificates (where/when available)
A durable technical fix is to remove the “single dual-use certificate” dependency and allow separate:
- Server certificate for inbound connections/UI
- Client certificate for outbound/mTLS scenarios
Some products may deliver this earlier than others; others may have longer lead times. Plan mitigations accordingly.
Recommended action plan (quick checklist)
- Now: Inventory all public certs and identify combined EKU usage.
- Next: Contact your CA to confirm their combined EKU support and timelines (and whether an alternate chain/route exists).
- Before renewal: Ensure your renewal request will produce the EKUs your deployment requires.
- If you use Expressway + automated public cert renewal: treat as urgent—validate what will be issued on next renewal and plan alternatives.
- Track vendor guidance: follow field notices/advisories and product updates for certificate split support.
Stay informed
Because this is an ecosystem-wide change (Chrome policy + CA issuance behavior + shortening certificate lifetimes), the situation will continue evolving. The safest approach is to assume that default issuance profiles will change, and to make certificate EKU requirements an explicit part of your operational process—not an implicit assumption.
Learn more:
If you have questions, contact: ask-collaboration-eku@external.cisco.com
Impact of Certificate EKU Changes for Cisco Customers Webinar Registration
Voice of Engineer Webinar: (Cisco and Partners only)
Field Notice FN74345: UCM/SME/IM&P/CUC/CER
Field Notice FN74362: Expressway
Field Notice FN74350: CUBE
About The Author
