Detta informerar er om en kommande ändring av webbläsarpolicyn för Google Chrome som påverkar utfärdandet av offentliga TLS-certifikat och för att beskriva de åtgärder som Cisco kommer att vidta för att säkerställa fortsatt stöd för ömsesidiga TLS-anslutningar (mTLS) i Cisco Webex Calling Dedicated Instance och UCM Cloud-miljöer.

Från och med den 1 februari 2027 kommer offentliga certifikatutfärdare (CA) som ingår i Google Chromes förtroendeprogram att sluta signera certifikat som inkluderar klientautentisering (clientAuth) Extended Key Usage (EKU).

Från och med den 15 mars 2027 kommer Google att tillämpa en policy som kräver att offentliga rot-CA:er i Chrome Root Store utfärdar certifikat som endast innehåller serverautentiserings-EKU:n (serverAuth). Som ett resultat kommer offentliga rot-CA:er i Chrome Root Store inte längre att tillåtas utfärda certifikat som kombinerar både serverautentisering och klientautentiserings-EKU:er i ett enda certifikat.

Dedikerade instans-UC-applikationer använder för närvarande certifikat som inkluderar både serverautentisering och klientautentiserings-EKU:er inom ett enda certifikat för att upprätta förtroende för mTLS-anslutningar. Stöd för separata server- och klientcertifikat förväntas introduceras med UC-applikationsversionen v15SU5, planerad till senare under 2026.

För närvarande använder Dedicated Instance IdenTrust Commercial Root CA 1, en del av Google Chrome Root Store, för att signera dessa certifikat. På grund av den kommande ändringen av Chromes policy kommer denna certifikatutfärdare dock inte längre att tillåtas utfärda certifikat som innehåller båda EKU:erna i ett enda certifikat från och med den 1 februari2027.

Certifikat som påverkas

Följande UC-applikationscertifikat signeras med en offentlig rot-CA och används vanligtvis för mTLS-anslutningar:

UC-ansökan	Certifikattyp	Vanliga mTLS-anslutningar
Cisco Unified CM / Små och medelstora företag	Hankatt / Tomcat-ECDSA	LDAP, Filebeat, Logstash, SIP OAuth över MRA, fjärrstyrd syslog
	Samtalshanterare / CallManager-ECDSA	SIP-trunkar, anslutningar mellan noder och kluster
Cisco Unity Connection	Hankatt / Tomcat-ECDSA	SIP-proxy, SIP-trunkar
Cisco IM och Presence	Hankatt / Tomcat-ECDSA	—
	kopp / kopp-ECDSA	Säker SIP med CUCM, tredjepartsklienter, SIP-proxy
	cup-xmpp / cup-xmpp-ECDSA	XMPP-sammanslagning
Cisco Emergency Responder	Hankatt / Tomcat-ECDSA	—
Cisco Expressway	Servercertifikat	Mobil och Remote Access (MRA)

Certifikat påverkas inte

Alla återstående certifikat i den dedikerade instansen är självsignerade. För ytterligare information, se Hantering av dedikerade instanscertifikat.

För att åtgärda Chrome-policyändringen och upprätthålla oavbruten mTLS-funktionalitet kommer Cisco att vidta följande åtgärder:

• Från och med den 1 juni2026kommer Cisco att byta den offentliga rot-CA som används för att signera UC-applikationscertifikat för dedikerade instanser från IdenTrust Commercial Root CA 1 till IdenTrust Public Sector Root CA 1 för alla certifikatförnyelser.

  Certifikatförnyelseprocessen förblir densamma, och Control Hub Alerts Center meddelar kunder via aviseringen "Underhåll och avbrott" när förnyelsen är schemalagd. För mer information, se Underhållsmeddelanden.

• Certifikat kommer att fortsätta att inkludera både server- och klientautentiserings-EKU:er.

Kunder och partners måste slutföra följande åtgärder för att säkerställa fortsatt tjänstekompatibilitet :

1. Granska aktuella mTLS-anslutningar
   1. Identifiera offentliga TLS-certifikat som inkluderar klientautentiserings-EKU:n.
   2. Kontrollera om de anslutande applikationerna litar på den nya offentliga rot-CA:n.
2. Lägg till den nya offentliga rot-CA:n (om det behövs)
   1. Om IdenTrust Public Sector Root CA 1 inte redan är betrodd i din miljö måste den läggas till.
   2. Rotcertifikatet kan laddas ner från IdenTrusts publika arkiv.

IdenTrust Public Sector Root CA 1 är som standard betrodd i standardförtroendearkiv för följande operativsystem och plattformar:

• Microsoft Windows
• macOS
• iOS / iPadOS
• Android

Därför krävs ingen kundåtgärd för slutpunkter eller system som använder standardförtroendearkiv på dessa plattformar, såvida inte förtroendearkivet uttryckligen har ändrats eller begränsats av kundpolicyn.

Android Trust Store-anteckning

IdenTrust Public Sector Root CA 1 ingår i Android-systemets CA-arkiv och är betrodd som standard på Android-versioner som för närvarande stöds. Android tillhandahåller ingen offentlig, versionsspecifik mappning för enskilda introduktionsdatum för rotcertifikat. Förtroende hanteras via Android-systemets CA-butik och distribueras via operativsystemuppdateringar och Google Play-systemuppdateringar.

Ingen kundåtgärd krävs om inte Android-systemets förtroendearkiv uttryckligen har ändrats av enhetspolicy, företagshanteringskontroller eller applikationsspecifika förtroendebegränsningar.

IdenTrust Public Sector Root CA 1 ingår inte i Google Chromes rotbutik.

För att säkerställa att Google Chrome litar på certifikat som utfärdats under denna rot-CA måste kunder se till att rotcertifikatet uttryckligen är betrott på operativsystemnivå på platser som Chrome använder för lokala förtroendebeslut.

Windows – obligatorisk förtroendekonfiguration

För att säkerställa att rot-CA:n är betrodd av Google Chrome i Windows måste IdenTrust Public Sector Root CA 1 importeras till en av följande platser:

• Lokal dator → Betrodda rotcertifikatutfärdare

  (Rekommenderas för företagshanterade system)

eller

• Nuvarande användare → Betrodda rotcertifieringsutfärdare

  (För förtroende på användarnivå)

Certifikat som importeras med hjälp av Windows certifikatimportguide till dessa platser (inklusive via gruppolicy) är betrodda av Google Chrome.

Rotcertifikat som bara finns i Windows tredjepartscertifikat är inte automatiskt betrodda av Chrome om de inte uttryckligen importeras enligt beskrivningen ovan.

Mac OS – obligatorisk förtroendekonfiguration

För att säkerställa att rot-CA:n är betrodd av Google Chrome på macOS måste IdenTrust Public Sector Root CA 1 läggas till i macOS-nyckelringen och uttryckligen vara betrodd:

1. Importera certifikatet till systemnyckelringen (rekommenderas) eller inloggningsnyckelringen

2. Öppna certifikatet och ställ in:

   • När du använder detta certifikat: Lita alltid på

     (eller åtminstone SSL: Alltid lita på)

När certifikatet är betrott på system- eller användarnivå kommer Google Chrome att acceptera det som betrott.

Administratörer kan verifiera vilka plattformscertifikat som är betrodda av Chrome genom att navigera till: chrome://certificate-manager/localcerts/platformcerts

För mer information, se Google FAQ.

Tredjepartsintegrationer representerar det primära område som kräver kundvalidering.

För alla tredjepartsapplikationer eller tjänster som upprättar mTLS-anslutningar med UC-applikationer för dedikerade instanser måste kunderna:

• Validera att tredjepartssystemet litar på IdenTrust Public Sector Root CA 1
• Arbeta direkt med tredjepartsleverantören om uppdateringar av betrodda arkiv eller ändringar i certifikatutfärdaren krävs

Kunder kan validera anslutning och förtroende för den nya publika rot-CA:n genom att öppna följande IdenTrust-testcertifikat.

Om det här certifikatet öppnas utan förtroendevarningar är IdenTrust Public Sector Root CA 1 redan betrodd i miljön.

Om du har frågor angående den här ändringen, webbläsarpolicyn för Google Chrome eller certifikatuppdateringar i dedikerad instans, öppna en serviceförfrågan i Control Hub under UC-applikationslivscykel.

UCM Cloud (UCMC)-kunder som äger sin domän och hanterar sina egna förnyelser av UC-applikationscertifikat och som inte har delegerat domänbehörighet till Cisco för att signera UC-applikationscertifikat kommer att ansvara för att arbeta direkt med sina valda offentliga certifikatutfärdare för att åtgärda denna förändring.

Dessa kunder bör också följa rekommendationerna från tillämpliga UC-applikationsprodukter ( Cisco on-prem calling products och Cisco Expressway) gällande certifikatanvändning och åtgärd relaterade till kommande ändringar av offentliga certifikatutfärdare och webbläsarpolicyer. För mer information, se Roller och ansvar.

Cisco kommer att fortsätta att tillhandahålla uppdateringar allt eftersom UC-applikationers stöd för separata server- och klientcertifikat blir tillgängligt. Se detta dokument för de senaste uppdateringarna.

Ändringar i certifikat-EKU: Åtgärder som Ciscos lokala samarbeteskunder MÅSTE VIDTA NU