Takk for tilbakemeldingen.

Dette er for å informere deg om en kommende endring i Google Chrome-nettleserpolic yen som påvirker utstedelsen av offentlige TLS- sertifikater, og for å skissere handlingene Cisco vil ta for å sikre fortsatt støtte for gjensidige TLS-tilkoblinger (MTL) i Dedicated Instance og UC Cisco Webex Calling M Cloud-miljøer.

Fra og med 1. februar 2027 vil offentlige sertifikatmyndigheter (CA) som er inkludert i Google Chrome Tru ^st- programmet, slutte å signere sertifikater som inkluderer klient autentisering (ClientAuth) Extended Key Usage (EKU).

Fra 15. mars 202 ⁷ håndhever Google en policy som krever at offentlige rot -CAer i Chrome Root Store utsteder sertifikater som bare inneholder Server Authentication (ServerAuth) EKU. Som et resultat vil offentlige root-CAer i Chrome Root Store ikke lenger ha tillatelse til å utstede sertifikater som kombinerer både serverautentisering og klient autentisering EKUer i ett enkelt sertifikat.

UC-applikasjoner for dedikerte instanser bruker for øyeblikket sertifikater som inkluderer både server autentisering og klientautentisering EKUer i ett enkelt sertifikat for å etablere tillit for MTL-tilkoblinger. Støtte for separate server- og klientsertifikater er nå tilgjengelig med UC-programutgivelsen V15su5.

For øyeblikket bruker Dedicated Instance IdenTrust Commercial Root CA 1, en del av Google Chrome Root Store, til å signere disse sertifikatene. På grunn av den kommende Chrome-policyen dringen vil imidlertid denne CA ikke lenger ha tillatelse til å utstede sertifikater som inneholder begge EKUer i ett enkelt sertifikat fra 1. februar ²⁰² 7.

Sertifikater påvirket

Følgende UC-programsertifikater signeres ved hjelp av en Public Root CA og brukes ofte for MTL-tilkoblinger:

UC-applikasjon	Sertifikattype	Vanlige MTLS-tilkoblinger
Cisco Unified CM/SMB	Tomkatt/Tomcat-ECDSA	LDAP, Filebeat, Logstash, SIP OAuth over MRA, Ekstern Syslog
	CallManager/CallManager-ECDSA	SIP-trunker, Inter-node- og Inter-cluster-tilkoblinger
Cisco Unity Connection	Tomkatt/Tomcat-ECDSA	SIP-proxy, SIP-trunker
Cisco IM og tilstedeværelse	Tomkatt/Tomcat-ECDSA	—
	kopp/kopp-ECDSA	Sikker SIP med CUCM, tredjepartsklienter, SIP Proxy
	kopp-xmpp/kopp-XMPP-ECDSA	XMPP-føderasjonen
Cisco Emergency Responder	Tomkatt/Tomcat-ECDSA	—
Cisco Expressway	Serversertifikat	Mobil og Remote Access (MRA)

Sertifikater påvirkes ikke

Alle gjenværende sertifikater i dedikert forekomst er selvsignerte. Hvis du vil ha mer informasjon, kan du se Sertifikatbehandling for dedikert forekomst.

For å håndtere Chrome-policyendringen og opprettholde uavbrutt MTL-funksjonalitet, vil Cisco utføre følgende tiltak:

• Med virkning fra 1. juni 2026 by ^{tter Cisco Public Root CA som brukes til signering av UC-applikasjonssertifikater for dedikerte instanser fra IdenTrust Commercial Root CA 1 til IdenTrust Public Sector Root CA 1 for alle sertifikatfornyelser.}

  Pros essen for fornyelse av sertifikatet forblir den samme, og Control Hub Alerts Center varsler kundene via varselet "Vedlikehold og avbrudd" når fornyelsen er planlagt. Hvis du vil ha mer informasjon, kan du se Ved likeholdsvarsler.

• Sertifikater vil fortsette å inkludere både server- og klientautentisering EKUer.

Eventuelle tredjepartsprogrammer eller -tjenester i kundemiljøet som kobler UC- applikasjoner i dedikert forekomst ved hjelp av TLS- eller MTLS-tilkoblinger, må bruke samme sertifikatkjede som UC-programmene i dedikert forekomst. Hvis klareringslageret for kundesystemer eller applikasjoner ikke allerede inneholder de nødvendige IdenTrust-sertifikat myndighetene, må det nye rotsertifikatet importeres for å forhindre TLS/MTLS-tilkoblingsfeil.

1. Reviser gjeldende MTLS-tilkoblinger
   1. Identifiser programmer, tredjepartstjenester eller integrasjoner som kobles til UC-applikasjonene i dedikert forekomst ved hjelp av TLS eller MTL-er.
   2. Kontroller om disse programmene stoler på den nye Public Root CA: IdenTrust Public S ector Root CA 1.
2. Legg til New Public Root CA (hvis nødvendig)
   1. Hvis IdenTrust Public Sector Root CA 1 ikke allerede er klarert i kundeprogrammet eller systemklareringslageret, må den legges til.
   2. Det samme kan lastes ned fra følgende lenker:

      Root CA: IdenTrust Public Sector Root CA 1

      Alternativ nedlastingsside: Ned lastinger av IdenTrust Support

      Utstedelse/underCA: IdenTrust Public Sector Server CA 1.

   For de fleste applikasjoner er det tilstrekkelig å stole på Root CA hvis serveren presenterer hele kjeden. Utstedelse/undersertifiseringscertifikat er fordelaktig å inkludere for applikasjoner som krever at mellomsertifikatet importeres separat.

IdenTrust Public Sector Root CA 1 er klarert som standard i standardklareringslagrene for følgende operativsystemer og plattformer:

• Microsoft Windows
• MacOS
• iOS /iPadOS
• Android

Som et resultat er kunden bare pålagt å validere klareringslagrene for disse plattformene for å bekrefte at rotsertifikatet til den nye offentlige CA allerede er oppført. Dette gjelder endepunkter/klienter eller tredjepartssystemer som bruker standard klareringslagre på disse plattformene. Instruksjoner for oppdatering av klareringsbutikken på hver plattform er gitt i avsnittene nedenfor. Ansvaret for å utføre disse oppdateringene ligger hos kunden eller partneren; lenkene og trinnene nedenfor refererer til elektroniske artikler fra de respektive plattformleverandørene, og Cisco gir assistanse etter beste innsats. For ytterligere avklaring må du samarbeide direkte med de respektive plattformleverandørene.

Android-tillitsbutikkmerknad

IdenTrust Public Sector Root CA 1 er inkludert i CA-butikken for Android-systemet og er klarert som standard på Android-versjoner som støttes for øyeblikket. Android gir ikke en offentlig, versjonsspesifikk kartlegging for individuelle introduksjonsdatoer for rotsertifikat. Til lit administreres gjennom Android-systemets CA-butikk og distribueres via operativsystemoppdateringer og Google Play-systemoppdateringer.

Ingen kundehandling er nødvendig med mindre Android-systemtillitslageret er blitt eksplisitt endret av enhetspolicyer, virksomhetsstyringskontroller eller applikasjonsspesifikke tillit sbegrensninger.

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

For å sikre at Google Chrome stoler på sertifikater som er utstedt under denne rotcertifikatutfärderen, må kundene sørge for at rotsertifikatet er eksplisitt klarert på operativsystemnivå på steder som Chrome bruker for lokale tillitsbeslutninger.

Windows — påkrevd tillitskonfigurasjon

For å sikre at rot-sertifiseringsinstansen er klarert av Google Chrome på Windows, må IdenTrust Public Sector Root CA 1 importeres til ett av følgende steder:

• Lokal datamaskin → Pålitelige rotsertifiseringsmyndigheter

  (Anbefales for bedriftsadministrerte systemer)

eller

• Nåværende bruker → Pålitelige rotsertifiseringsmyndigheter

  (For tillit på brukernivå)

Sertifikater som importeres ved hjelp av Windows Certificate Import Wizard til disse stedene (inkludert via gruppepolicy) klareres av Google Chrome.

Rotsertifikater som bare finnes i Windows tredjepart klareres ikke automatisk av Chrome med mindre de eksplisitt importeres som beskrevet ovenfor.

Mac OS — påkrevd tillitskonfigurasjon

For å sikre at rotsertifiseringen er klarert av Google Chrome på macOS, må IdenTrust Public Sector Root CA 1 legges til i macOS-nøkkelringen og eksplisitt klareres:

1. Importer sertifikatet til systemnøkkelring (anbefales) eller påloggingsnøkkelring

2. Åpne sertifikatet og sett:

   • Når du bruker dette sertifikatet: Stol alltid på

     (eller minst SSL: Always Trust)

Når det er klarert på system- eller brukernivå, vil Google Chrome respektere sertifikatet som klar ert.

Administratorer kan bekrefte hvilke plattformsertifikater Chrome klarerer ved å gå til: chrome: //certificate-manager/localcerts/platformcerts

Hvis du vil ha mer informasjon, kan du se Van lige spørsmål om Google.

Tredjepartsintegrasjoner krever primær kundevalidering.

For tredjepartsprogrammer eller -tjenester som oppretter TLS/MTLS-tilkoblinger med UC-applikasjoner for dedikert forekomst, må kundene følge handlingene som er nevnt i Offentlige sertifikatendringer som påvirker dedikert forekomst.

Du må samarbeide direkte med tredjepartsleverandøren eller IT-administratoren hvis oppdateringene for klareringsbutikken er påkrevd. Endringer i tredjeparts klareringslagre eller atferd for sertifikat validering er utenfor Ciscos ansvar, og Cisco kan ikke bistå med tredjeparts sertifikattillitskonfigurasjoner eller feilsøking.

Kunder kan validere den nye Public Root CA-en ved å bruke IdenTrust testsertifikatet.

Hvis siden åpnes, er IdenTrust Public Sector Root CA 1 klarert i miljøet ditt.

Hvis du har spørsmål angående denne endringen, Google Chrome-nettleserpolicyen eller sertifikat oppdateringer i Dedikert forekomst, åpner du en tjenesteforespørsel i Control Hub under UC-applikasjonens livssyklus.

UCM Cloud-kunder (UCMC) som eier domenet sitt og administrerer sine egne fornyelser av UC-applikasjons sertifikater, og som ikke har delegert domeneautoritet til Cisco for signering av UCM- applikasjonssertifikater, vil være ansvarlige for å samarbeide direkte med de valgte offentlige sertifikatmyndighetene for å håndtere denne endringen. 

Disse kundene bør også samsvare med anbefalingene for gjeldende UC-applikasjonsprodukt (Ciscos lokale anropsprodukter og Cisco Expressway) angående sertifikatbruk og utbedring knyttet til kommende endringer i Public CA og nettleserpolicyer. Hvis du vil ha mer informasjon, kan du se Roller og ansvar. 

Cisco vil fortsette å tilby oppdateringer etter hvert som UC-applikasjonsstøtte for separate server- og klientsertifikater blir tilgjengelig. Se dette dokumentet for de siste oppdateringene.

Sertifikat EKU-endringer: Handlinger Cisco lokale samarbeidskunder MÅ TA NÅ