Tak for din feedback.

Dette er for at informere dig om en kommende ændring af Google Chrome-browserpolitik, der påvirker udstedelsen af offentlige TLS- certifikater, og for at skitsere de handlinger, Cisco vil tage for at sikre fortsat support til gensidige TLS-forbindelser (MTL) i Dedicated Instance og UC Cisco Webex Calling M Cloud-miljøer.

Fra 1. februar 2027 vil offentlige certifikatmyndigheder (CA'er), der er inkluderet i Google Chrome Tru ^st- programmet, stoppe med at underskrive certifikater, der inkluderer klient godkendelse (ClientAuth) Extended Key Usage (EKU).

Med virkning fra den 15. ^marts 2027 håndhæver Google en politik, der kræver, at offentlige rodCA'er i Chrome Root Store udsteder certifikater, der kun indeholder EKU for servergodkendelse (ServerAuth). Som følge heraf vil offentlige rodcertifikatører i Chrome Root Store ikke længere have tilladelse til at udstede certifikater, der kombinerer både servergodkendelse og klient godkendelse EKU'er i et enkelt certifikat.

UC-programmer med dedikerede instanser bruger i øjeblikket certifikater, der inkluderer både server godkendelse og klientgodkendelse EKU'er i et enkelt certifikat for at etablere tillid til MTLS-forbindelser. Understøttelse af separate server- og klientcertifikater er nu tilgængelig med UC-programudgivelsen V15su5.

I øjeblikket bruger Dedicated Instance IdenTrust Commercial Root CA 1, der er en del af Google Chrome Root Store, til at underskrive disse certifikater. På grund af den kommende Chrome-politik ændring vil denne CA dog ikke længere have tilladelse til at udstede certifikater, der indeholder begge EKU'er i et enkelt certifikat fra 1. februar ²⁰² 7.

Påvirkede certifikater

Følgende UC-applikationscertifikater underskrives ved hjælp af en Public Root CA og bruges almindeligvis til MTLS-forbindelser:

UC-applikation	Certifikattype	Almindelige MTLS-forbindelser
Cisco Unified CM/SMV	Tomkat/Tomcat-ECDSA	LDAP, Filebeat, Logstash, SIP OAuth over MRA, Fjernsyslog
	Opkaldshåndtere/CallManager-ECDSA	SIP-trunker, forbindelser mellem knuder og interklynger
Cisco Unity Connection	Tomkat/Tomcat-ECDSA	SIP-proxy, SIP-trunker
Cisco IM og tilstedeværelse	Tomkat/Tomcat-ECDSA	—
	kop/kop-ECDSA	Sikker SIP med CUCM, tredjepartsklienter, SIP Proxy
	kop-xmpp/kop-XMPP-ECDSA	XMPP-føderationen
Cisco Emergency Responder	Tomkat/Tomcat-ECDSA	—
Cisco Expressway	Servercertifikat	Mobil og Remote Access (MRA)

Certifikater påvirkes ikke

Alle resterende certifikater i Dedicated Instance er selvsignerede. Yderligere oplysninger finder du i Administration af certifikater for dedikeret forekomst.

For at løse Chrome-politikændringen og opretholde uafbrudt MTLS-funktionalitet foret ager Cisco følgende handlinger:

• Med virkning fra 1. juni 2026 skif ^{ter Cisco den offentlige rodcertificeringscertifikat, der bruges til at underskrive UC-applikationscertifikater for dedikerede instanser, fra IdenTrust Commercial Root CA 1 til IdenTrust Public Sector Root CA 1 for alle certifikatfornyelser.}

  Processen for fornyelse af certifikatet forbliver den samme, og Control Hub Alerts Center giver kunderne besked via advarslen "Ved ligeholdelse og af brydelse", når fornyelsen er planlagt. Du kan finde flere oplysninger under Ved ligeholdelsesadvarsler.

• Certifikater vil fortsat omfatte både server- og klientgodkendelsesEKU'er.

Alle tredjepartsprogrammer eller -tjenester i kundemiljøet, der forbinder UC- programmer i dedikeret instans ved hjælp af TLS- eller mTLS-forbindelser, skal bruge den samme certifikatkæde som UC-applikationerne i Dedicated Instance. Hvis kundens systemer eller programmer ikke allerede indeholder de krævede IdenTrust-certifikat autoriteter, skal det nye rodcertifikat importeres for at forhindre TLS/MTLS-forbindelsesfejl.

1. Overvåg aktuelle MTLS-forbindelser
   1. Identificer programmer, tredjepartstjenester eller integrationer, der opretter forbindelse til UC -applikationerne i dedikeret instans ved hjælp af TLS eller MTL'er.
   2. Kontroller, om disse programmer har tillid til den nye Public Root CA: IdenTrust Public S ector Root CA 1.
2. Tilføj den nye offentlige rodcertifikatudbyder (hvis nødvendigt)
   1. Hvis der ikke allerede er tillid til IDEntrust Public Sector Root CA 1 i kundeprogrammet eller systemtillidslageret, skal det tilføjes.
   2. Det samme kan downloades fra følgende links:

      Root CA: IdenTrust Public Sector Root CA 1

      Alternativ downloadside: Down loads af IdenTrust Support

      Udstedelse/underCA: IdenTrust Public Sector Server CA 1.

   For de fleste applikationer er det tilstrækkeligt at stole på Root CA'en, hvis serveren præsenterer hele kæden. Udstedelses-/undercertifikatet er fordelagtigt at medtage for applikationer, der kræver , at mellemcertifikatet importeres separat.

Der er som standard tillid til IDEntrust Public Sector Root CA 1 i standardtillidslagr ene for følgende operativsystemer og platforme:

• Microsoft Windows
• MacOS
• iOS /iPadOS
• Android

Som følge heraf er kunden kun forpligtet til at validere tillidslagrene for disse platforme for at bekræfte, at rodcertifikatet for den nye offentlige CA allerede er angivet. Dette gælder for slutpunkter/klienter eller tredjepartssystemer, der bruger standardtillidslagrene på disse platforme. Instruktioner til opdatering af tillidsbutikken på hver platform findes i afsnittene nedenfor. Ansvaret for at udføre disse opdateringer ligger hos kunden eller partneren; nedenstående links og trin henviser til onlineartikler fra de respektive platformsleverandører, og Cisco y der assistance efter bedste indsats. For yderligere afklaring skal du arbejde direkte med de respektive platformsleverandører.

Bemærkning til Android-tillidsbutik

IdenTrust Public Sector Root CA 1 er inkluderet i Android-systemets CA-butik og er som standard betroet på Android-versioner, der i øjeblikket understøttes. Android giver ikke en offentlig, versionsspecifik kortlægning for individuelle rodcertifikatintroduktionsdatoer. Til lid administreres gennem Android-systemets CA-butik og distribueres via operativsystemopdateringer og Google Play-systemopdateringer.

Ingen kundehandling er påkrævet, medmindre Android-systemets tillidslagring eksplicit er blevet ændret af enhedspolitik, virksomhedsledelseskontroller eller applikationsspecifikke tillidsbegrænsninger.

IdenTrust Public Sector Root CA 1 er ikke inkluderet i Google Chrome Root Store.

For at sikre, at Google Chrome har tillid til certifikater, der er udstedt under denne rodcertificeringscertifikat, skal kunderne sikre , at rodcertifikatet udtrykkeligt er tillid til på operativsystemniveau på steder, som Chrome bruger til lokale beslutninger om tillid.

Windows — påkrævet tillidskonfiguration

For at sikre, at Google Chrome har tillid til rodcertifikatet i Windows, skal IdenTrust Public Sector Root CA 1 importeres til en af følgende placeringer:

• Lokal computer → Pålidelige rodcertificeringsmyndigheder

  (Anbefales til virksomhedsstyrede systemer)

eller

• Nuværende bruger → Pålidelige rodcertificeringsmyndigheder

  (Til tillid på brugerniveau)

Certifikater, der importeres ved hjælp af guiden Import af Windows-certifikater til disse placeringer (herunder via gruppepolitik), er betroet af Google Chrome.

Chrome har ikke automatisk tillid til rodcertifikater, der kun findes i tredjepart i Windows, medmindre de eksplicit importeres som beskrevet ovenfor.

Mac OS — påkrævet tillidskonfiguration

For at sikre, at Google Chrome har tillid til rodcertifikatet på macOS, skal IdenTrust Public Sector Root CA 1 føjes til macOS-nøgleringen og udtrykkeligt have tillid til:

1. Importer certifikatet til systemnøgleringen (anbefales) eller login-nøglering

2. Åbn certifikatet og indstil:

   • Når du bruger dette certifikat: Stol altid på

     (eller som minimum SSL: Always Trust)

Når du har tillid til på system- eller brugerniveau, anerkender Google Chrome certifikatet som betroet.

Administratorer kan kontrollere, hvilke platformscertifikater Chrome har tillid til, ved at navigere til: chrome: //certificate-manager/localcerts/platformcerts

Du kan finde flere oplysninger i Ofte stillede spørgsmål om Google.

Tredjepartsintegrationer kræver primær kundevalidering.

For tredjepartsprogrammer eller -tjenester, der opretter TLS/mTLS-forbindelser med UC-programmer med dedikerede instanser, skal kunderne følge de handlinger, der er nævnt i Offentlige certifikatændringer, der påvirker dedikeret forekomst.

Du skal samarbejde direkte med din tredjepartsleverandør eller it-administrator, hvis der kræves opdateringer af tillidslager. Ændringer af tredjeparts tillidslager eller certifikat valideringsadfærd er uden for Ciscos ansvar, og Cisco kan ikke hjælpe med konfigurationer af certifikattillid fra tredjeparter eller fejlfinding.

Kunder kan validere den nye Public Root CA ved hjælp af IdenTrust testcertifikatet.

Hvis siden åbnes korrekt, har du tillid til IdenTrust Public Sector Root CA 1 i dit miljø.

Hvis du har spørgsmål vedrørende denne ændring, Google Chrome-browserpolitikken eller certifikat opdateringer i Dedikeret forekomst, skal du åbne en serviceanmodning i Control Hub under UC-applikationens livscyklus.

UCM Cloud-kunder (UCMC), der ejer deres domæne og administrerer deres egne fornyelser af UC-applikationscer tifikater, og som ikke har delegeret domænemyndighed til Cisco til at underskrive UC- applikationscertifikater, er ansvarlige for at arbejde direkte med deres valgte offentlige certifikatautoriteter for at løse denne ændring. 

Disse kunder bør også tilpasse sig anbefalingerne til det relevante UC-applikationsprodukt (Ciscos on-prem call-produkter og Cisco Expressway) vedrørende certifikatbrug og afhjælpning i forbindelse med de kommende ændringer af Public CA og browserpolitik. Du kan finde flere oplysninger i Roller og ansvar. 

Cisco vil fortsætte med at levere opdateringer, efterhånden som UC-applikationsunderstøttelse af separate server- og klientcertifikater bliver tilgængelig. Se dette dokument for de seneste opdateringer.

Certifikat EKU-ændringer: Handlinger, som Ciscos lokale samarbejdskunder skal tage nu