Hierbij informeren wij u over een aanstaande beleidswijziging van de Google Chrome-browser die van invloed is op de uitgifte van openbare TLS-certificaten en over de maatregelen die Cisco zal nemen om de voortdurende ondersteuning van wederzijdse TLS-verbindingen (mTLS) in Cisco Webex Calling Dedicated Instance- en UCM Cloud-omgevingen te waarborgen.

Vanaf 1 februari 2027 zullen openbare certificeringsinstanties (CA's) die zijn opgenomen in het Google Chrome Trust-programma, stoppen met het ondertekenen van certificaten die de Client Authentication (clientAuth) Extended Key Usage (EKU) bevatten.

Met ingang van 15 maart 2027 zal Google een beleid handhaven dat vereist dat openbare root-CA's in de Chrome Root Store certificaten uitgeven die alleen de Server Authentication (serverAuth) EKU bevatten. Als gevolg hiervan is het openbare root-CA's in de Chrome Root Store niet langer toegestaan om certificaten uit te geven die zowel serverauthenticatie- als clientauthenticatie-EKU's in één certificaat combineren.

Dedicated Instance UC-applicaties gebruiken momenteel certificaten die zowel Server Authentication- als Client Authentication EKU's in één certificaat bevatten om vertrouwen te creëren voor mTLS-verbindingen. De ondersteuning voor aparte server- en clientcertificaten zal naar verwachting worden geïntroduceerd met de UC-applicatieversie v15SU5, die gepland staat voor later in 2026.

Momenteel gebruikt Dedicated Instance de IdenTrust Commercial Root CA 1, onderdeel van de Google Chrome Root Store, om deze certificaten te ondertekenen. Vanwege de aanstaande beleidswijziging van Chrome is het deze CA echter vanaf 1 februari^st, 2027 niet langer toegestaan om certificaten uit te geven die beide EKU's in één certificaat bevatten.

Betreffende certificaten

De volgende UC-applicatiecertificaten zijn ondertekend met behulp van een openbare root-CA en worden veelvuldig gebruikt voor mTLS-verbindingen:

UC-aanvraag	Type certificaat	Veelvoorkomende mTLS-verbindingen
Cisco Unified CM / MKB	Kater / Tomcat-ECDSA	LDAP, Filebeat, Logstash, SIP OAuth via MRA, Remote Syslog
	CallManager / CallManager-ECDSA	SIP-trunks, verbindingen tussen knooppunten en tussen clusters
Cisco Unity Connection	Kater / Tomcat-ECDSA	SIP-proxy, SIP-trunks
Cisco IM en Presence	Kater / Tomcat-ECDSA	—
	beker / cup-ECDSA	Beveiligde SIP met CUCM, clients van derden en SIP-proxy.
	cup-xmpp / cup-xmpp-ECDSA	XMPP-federatie
Cisco Emergency Responder	Kater / Tomcat-ECDSA	—
Cisco Expressway	Servercertificaat	Mobile and Remote Access (MRA)

Certificaten worden niet beïnvloed.

Alle overige certificaten in de Dedicated Instance zijn zelfondertekend. Zie voor meer informatie Certificaatbeheer voor dedicated instances.

Om de beleidswijziging van Chrome te verwerken en de ononderbroken werking van mTLS te waarborgen, zal Cisco de volgende actie ondernemen:

• Met ingang van 1 juni¹2026zal Cisco de openbare root-CA die wordt gebruikt voor het ondertekenen van UC-applicatiecertificaten voor Dedicated Instances wijzigen van IdenTrust Commercial Root CA 1 naar IdenTrust Public Sector Root CA 1 voor alle certificaatvernieuwingen.

  Het proces voor certificaatvernieuwing blijft hetzelfde en het Control Hub Alerts Center informeert klanten via de melding "Onderhoud en storing" wanneer de vernieuwing gepland staat. Voor meer informatie, zie Onderhoudsmeldingen.

• Certificaten zullen zowel EKU's voor server- als clientauthenticatie blijven bevatten.

Klanten en partners moeten de volgende stappen uitvoeren om de continue compatibiliteit van de dienstverlening te waarborgen. :

1. Controleer de huidige mTLS-verbindingen
   1. Identificeer openbare TLS-certificaten die de Client Authentication EKU bevatten.
   2. Controleer of de verbindende applicaties de nieuwe openbare root-CA vertrouwen.
2. Voeg de nieuwe openbare root-CA toe (indien nodig)
   1. Als de IdenTrust Public Sector Root CA 1 nog niet vertrouwd is in uw omgeving, moet deze worden toegevoegd.
   2. Het rootcertificaat kan worden gedownload van de openbare repository van IdenTrust.

De IdenTrust Public Sector Root CA 1 wordt standaard vertrouwd in de standaard vertrouwensarchieven voor de volgende besturingssystemen en platforms:

• Microsoft Windows
• macOS
• iOS / iPadOS
• Android

Hierdoor is er geen actie van de klant vereist voor eindpunten of systemen die gebruikmaken van standaard vertrouwensarchieven op deze platforms, tenzij het vertrouwensarchief expliciet is gewijzigd of beperkt door het klantbeleid.

Android-vertrouwensopslagnotitie

De IdenTrust Public Sector Root CA 1 is opgenomen in de CA-opslag van het Android-systeem en wordt standaard vertrouwd op de momenteel ondersteunde Android-versies. Android biedt geen openbaar, versie-specifiek overzicht van de introductiedata van individuele rootcertificaten. Vertrouwen wordt beheerd via de CA-store van het Android-systeem en verspreid via updates van het besturingssysteem en updates van Google Play.

Er is geen actie van de klant vereist, tenzij de vertrouwensopslag van het Android-systeem expliciet is gewijzigd door apparaatbeleid, beheertools voor bedrijven of toepassingsspecifieke vertrouwensbeperkingen.

De IdenTrust Public Sector Root CA 1 is niet opgenomen in de Google Chrome Root Store.

Om ervoor te zorgen dat Google Chrome certificaten vertrouwt die zijn uitgegeven onder deze root-CA, moeten klanten ervoor zorgen dat het rootcertificaat expliciet wordt vertrouwd op besturingssysteemniveau op locaties die Chrome gebruikt voor lokale vertrouwensbeslissingen.

Windows – vereiste vertrouwensconfiguratie

Om ervoor te zorgen dat de root-CA door Google Chrome op Windows wordt vertrouwd, moet de IdenTrust Public Sector Root CA 1 worden geïmporteerd naar een van de volgende locaties:

• Lokale computer → Vertrouwde basiscertificeringsinstanties

  (Aanbevolen voor door bedrijven beheerde systemen)

of

• Huidige gebruiker → Vertrouwde basiscertificeringsinstanties

  (Voor vertrouwen op gebruikersniveau)

Certificaten die met behulp van de Windows-wizard voor certificaatimport naar deze locaties zijn geïmporteerd (ook via groepsbeleid) worden door Google Chrome vertrouwd.

Rootcertificaten die alleen in de Windows-app van derden aanwezig zijn, worden niet automatisch door Chrome vertrouwd, tenzij ze expliciet worden geïmporteerd zoals hierboven beschreven.

Mac OS – vereiste vertrouwensconfiguratie

Om ervoor te zorgen dat de root-CA door Google Chrome op macOS wordt vertrouwd, moet de IdenTrust Public Sector Root CA 1 aan de macOS-sleutelbos worden toegevoegd en expliciet als vertrouwd worden ingesteld:

1. Importeer het certificaat in de systeem-sleutelbos (aanbevolen) of de aanmeldsleutelbos.

2. Open het certificaat en stel het volgende in:

   • Bij gebruik van dit certificaat: Altijd vertrouwen

     (of minimaal SSL: Altijd vertrouwen

Zodra het certificaat op systeem- of gebruikersniveau als betrouwbaar wordt beschouwd, zal Google Chrome het certificaat als zodanig erkennen.

Beheerders kunnen controleren welke platformcertificaten door Chrome worden vertrouwd door naar de volgende locatie te navigeren: chrome://certificate-manager/localcerts/platformcerts

Voor meer informatie, zie Google FAQ.

Integraties met externe partijen vormen het belangrijkste gebied waar klantvalidatie vereist is.

Voor alle applicaties of services van derden die mTLS-verbindingen tot stand brengen met Dedicated Instance UC-applicaties, moeten klanten het volgende doen:

• Controleer of het systeem van de derde partij de IdenTrust Public Sector Root CA 1 vertrouwt.
• Neem rechtstreeks contact op met de externe leverancier als er updates van de vertrouwensopslag of wijzigingen in de CA nodig zijn.

Klanten kunnen de connectiviteit en het vertrouwen in de nieuwe openbare root-CA valideren door het volgende IdenTrust-testcertificaatte raadplegen.

Als dit certificaat zonder problemen en zonder waarschuwingen over vertrouwen kan worden geopend, wordt de IdenTrust Public Sector Root CA 1 al vertrouwd in de omgeving.

Als u vragen hebt over deze wijziging, het Google Chrome-browserbeleid of certificaatupdates in Dedicated Instance, kunt u een serviceverzoek indienen in Control Hub onder UC-applicatielevenscyclus.

UCM Cloud (UCMC)-klanten die eigenaar zijn van hun domein en zelf de verlenging van hun UC-applicatiecertificaten beheren, en die Cisco geen bevoegdheid hebben gegeven om UC-applicatiecertificaten te ondertekenen, zijn zelf verantwoordelijk voor het rechtstreeks samenwerken met hun gekozen openbare certificeringsinstanties om deze wijziging door te voeren.

Deze klanten dienen zich ook te houden aan de aanbevelingen van het betreffende UC-applicatieproduct ( Cisco on-prem calling products en Cisco Expressway) met betrekking tot certificaatgebruik en herstelmaatregelen in verband met de aanstaande wijzigingen in het beleid van de Public CA en browsers. Zie Rollen en verantwoordelijkhedenvoor meer informatie.

Cisco zal updates blijven verstrekken zodra ondersteuning voor UC-applicaties met aparte server- en clientcertificaten beschikbaar komt. Raadpleeg dit document voor de meest recente updates.

Wijzigingen in het EKU-certificaat: Acties die Cisco On-premises Collaboration-klanten NU MOETEN ondernemen