Tack för din feedback.

Detta för att informera dig 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 Cisco kommer att vidta för att säkerställa fortsatt stöd för ömsesidiga TLS-anslutningar (MTL) i Dedicated Instance och UC Cisco Webex Calling M Cloud-miljöer.

Från och med den 1 februari 2027 kommer offentliga certifikatutfärdare (CA) som ingår i Google Chrome Tru ^st- programmet att sluta signera certifikat som inkluderar klient autentisering (ClientAuth) Extended Key Usage (EKU).

Från och med den ¹⁵ mars 2027 kommer Google att tillämpa en policy som kräver att offentliga rotcertifikatutfär dare i Chrome Root Store utfärdar certifikat som endast innehåller serverautentisering (ServerAuth) EKU. Som ett resultat kommer offentliga rotcertifikatutfärdare i Chrome Root Store inte längre att tillåtas utfärda certifikat som kombinerar både serverautentisering och klient autentisering i ett enda certifikat.

UC-program för dedikerade instanser använder för närvarande certifikat som inkluderar både server autentisering och klientautentisering i ett enda certifikat för att skapa förtroende för MTL-anslutningar. Stöd för separata server- och klientcertifikat är nu tillgängligt med UC-programversion V15su5.

För närvarande använder Dedikerad instans IdenTrust Commercial Root CA 1, en del av Google Chrome Root Store, för att signera dessa certifikat. På grund av den kommande Chrome-policy ändringen kommer certifikatutfärdaren 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 ^februari 2027.

Certifikat påverkade

Följande UC-programcertifikat signeras med en offentlig rotcertifikatutfärdare och används ofta för MTL-anslutningar:

UC-applikation	Certifikattyp	Vanliga MTL-anslutningar
Cisco Unified CM/Små och medelstora företag	Tomkatt/Tomcat-ECDSA	LDAP, Filebeat, Logstash, SIP OAuth över MRA, Remote Syslog
	Samtalshanterare/samtalshanterare-ECDSA	SIP-trunkar, anslutningar mellan noder och kluster
Cisco Unity Connection	Tomkatt/Tomcat-ECDSA	SIP-proxy, SIP-trunkar
Cisco IM och närvaro	Tomkatt/Tomcat-ECDSA	—
	kopp/kopp-ECDSA	Säker SIP med CUCM, tredjepartsklienter, SIP Proxy
	kopp-xmpp/kopp-XMPP-ECDSA	XMPP-federationen
Cisco Emergency Responder	Tomkatt/Tomcat-ECDSA	—
Cisco Expressway	Servercertifikat	Mobil och Remote Access (MRA)

Certifikat påverkas inte

Alla återstående certifikat i Dedicated Instance är självsignerade. Mer information finns i Cer tifikathantering för dedikerade instanser.

För att åtgärda Chrome-policyändringen och upprätthålla oavbruten MTL-funktionalitet vid tar Cisco följande åtgärder:

• Från och med den 1 ^juni 2026 kommer Cisco att byta den offentliga rotcertifikatutfärdaren som används för att signera UC-programcertifikat för dedikerade instanser från IdenTrust Commercial Root CA 1 till IdenTrust Public Sector Root CA 1 för alla certifikatförnyelser.

  Proc essen för förnyelse av certifikat förblir densamma och Control Hub Alerts Center meddelar kunder via varningen "Under håll och avbrott" när förnyelsen är schemalagd. Mer information finns i Underhållsvarningar.

• Certifikaten kommer även fortsättningsvis att innehålla både server- och klientautentiserings-EKU.

Alla program eller tjänster från tredje part i kundmiljön som ansluter UC- program i Dedicated Instance med TLS- eller MTLS-anslutningar måste använda samma certifikatkedja som UC-programmen i Dedicated Instance. Om kundsystemets eller programmets förtro enderegister inte redan innehåller de nödvändiga IdenTrust-certifikatutfärdarna måste det nya rotcertifik atet importeras för att förhindra fel på TLS/MTLS-anslutningen.

1. Granska aktuella MTL-anslutningar
   1. Identifiera program, tredjepartstjänster eller integrationer som ansluter till UC- programmen i dedikerad instans med hjälp av TLS eller MTL.
   2. Kontrollera om dessa program litar på den nya Public Root CA: IdenTrust Public S ector Root CA 1.
2. Lägg till den nya offentliga rotcertifikatutfärdaren (om det behövs)
   1. Om IdenTrust Public Sector Root CA 1 inte redan är betrodd i kundprogrammet eller systemförtroenderegistret måste det läggas till.
   2. Detsamma kan laddas ner från följande länkar:

      Root CA: IdenTrust Public Sector Root CA 1

      Alternativ nedladdningssida: IdenTrust Support Nedladdningar

      Utgivande/undercertifikatutfärdare: IdenTrust Public Sector Server CA 1.

   För de flesta applikationer räcker det att lita på Root CA om servern presenterar hela kedjan. Utfärdande/undercertifikatet är fördelaktigt att inkludera för applikationer som kräver att mellancertifikatet importeras separat.

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

• Microsoft Windows
• MacOS
• iOS /iPadOS
• Android

Som ett resultat måste kunden endast validera förtroendelagren för dessa plattformar för att bekräfta att den nya offentliga certifikatutfärdarens rotcertifikat redan finns listat. Detta gäller slutpunkter/klienter eller tredjepartssystem som använder standardförtroendebutikerna på dessa plattformar. Instruktioner för uppdatering av förtroendebutiken på varje plattform finns i avsnitten nedan. Ansvaret för att utföra dessa uppdateringar ligger hos kunden eller partnern; länkarna och stegen nedan hänvisar till artiklar online från respektive plattformsleverantör, och Cisco tillhandahåller hjälp på bästa sätt. För ytterligare förtydligande måste du arbeta direkt med respektive plattformsleverantörer.

Anmärkning om Android Trust Store

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

Ingen kundåtgärd krävs såvida inte Android-systemets förtroenderegister uttryckligen har ändrats av enhetsprincip, företagshanteringskontroller eller programspecifika förtro endebegränsningar.

IdenTrust Public Sector Root CA 1 ingår inte i Google Chrome Root Store.

För att säkerställa att Google Chrome litar på certifikat som utfärdats under denna rotcertifikatutfärdare måste kunderna se till att rotcertifikatet uttryckligen är betrodda på operativsystemnivå på platser som Chrome använder för lokala förtroendebeslut.

Windows — behövlig förtroendekonfiguration

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

• Lokal dator → Betrodda rotcertifieringsmyndigheter

  (Rekommenderas för företagshanterade system)

eller

• Nuvarande användare → Betrodda rotcertifieringsmyndigheter

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

Certifikat som importeras med hjälp av guiden Importera certifikat i Windows till dessa platser (inklusive via grupprincip) är betrodda av Google Chrome.

Rotcertifikat som bara finns i Windows tredje part betrodda inte automatiskt av Chrome såvida de inte uttryckligen importeras enligt beskrivningen ovan.

Mac OS — behövlig förtroendekonfiguration

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

1. Importera certifikatet till systemnyckelring (rekommenderas) eller inloggningsnyckelring

2. Öppna certifikatet och ställ in:

   • När du använder detta certifikat: Alltid lita på

     (eller åtminstone SSL: Always Trust)

När du är betrodd på system- eller användarnivå kommer Google Chrome att respektera certifikatet som betrodd.

Administratörer kan verifiera vilka plattformscertifikat som Chrome litar på genom att navigera till: chrome: //certificate-manager/localcerts/platformcerts

Mer information finns i Vanliga frågor om Google.

Tredjepartsintegrationer kräver primär kundvalidering.

För program eller tjänster från tredje part som upprättar TLS-/mTLS-anslutningar med UC-program för dedikerade instanser måste kunderna följa de åtgärder som nämns i Offentliga certifikatändringar som påverkar Dedikerad instans.

Du måste samarbeta direkt med din tredjepartsleverantör eller IT-administratör om uppdateringar av förtroendebutiken krävs. Ändringar av tredjeparts förtroendelager eller certifikat valideringsbeteenden ligger utanför Ciscos ansvar, och Cisco kan inte hjälpa till med konfigurationer av certifikatförtroende från tredje part eller felsökning.

Kunder kan validera den nya offentliga rotcertifikatutfärdaren med hjälp av testcertifikatet IdenTrust.

Om sidan öppnas framgångsrikt är IdenTrust Public Sector Root CA 1 betrodd i din miljö.

Om du har frågor om den här ändringen, webbläsarpolicyn för Google Chrome eller certifikat uppdateringar i Dedikerad instans öppnar du en serviceförfrågan i Control Hub under UC-programmets livscykel.

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

Dessa kunder bör också anpassa sig till rekommendationerna för tillämplig UC-applikationsprodukt (Ciscos on-prem call-produkter och Cisco Expressway) angående certifikatanvändning och avhjälpande åtgärder relaterade till kommande ändringar av Public CA och webbläsarpolicy. Mer information finns i Roller och ansvar. 

Cisco kommer att fortsätta att tillhandahålla uppdateringar när UC-applikationsstöd för separata server- och klientcertifikat blir tillgängligt. Se det här dokumentet för de senaste uppdateringarna.

Certifikat EKU-ändringar: Åtgärder som Ciscos lokala samarbetskunder MÅSTE VIDTA NU