Merci pour votre commentaire.

Ceci a pour but de vous informer d'une prochaine modification de la politique du navigateur Google Chrome qui aura un impact sur la délivrance de certificats TLS publics et de décrire les mesures que Cisco prendra pour garantir la prise en charge continue des connexions TLS mutuelles ( mTLS) dans les environnements Cisco Webex Calling Dedicated Instance et UCM Cloud.

À compter du ^1er février 2027, les autorités de certification publiques (CA) incluses dans le programme Google Chrome Trust cesseront de signer des certificats qui incluent l'utilisation étendue des clés (EKU) pour l' authentification du client (ClientAuth).

À compter ^du 15 mars 2027, Google appliquera une politique obligeant les autorités de certification root publiques du Chrome Root Store à émettre des certificats contenant uniquement l'EKU d'authentification du serveur (ServerAuth). Par conséquent, les autorités de certification root publiques du Chrome Root Store ne seront plus autorisées à émettre des certificats combinant à la fois l'authentification du serveur et l'authentification client dans un seul certificat.

Les applications UC d'instance dédiée utilisent actuellement des certificats qui incluent à la fois des EKU d'authentification du serveur et d'authentification client dans un seul certificat afin d'établir la confiance pour les connexions mTLS. La prise en charge de certificats serveur et client distincts est désormais disponible avec la version V15su5 de l'application UC.

Actuellement, Dedicated Instance utilise l'ID Trust Commercial Root CA 1, qui fait partie du Google Chrome Root Store, pour signer ces certificats. Cependant, en raison du prochain changement de politique de Chrome, cette autorité de certification ne sera plus autorisée à émettre des certificats contenant les deux EKU en un seul certificat à compter du ^1er février 2027.

Certificats concernés

Les certificats d'application UC suivants sont signés à l'aide d'une autorité de certification racine publique et sont couramment utilisés pour les connexions mTLS :

application UC	Type de certificat	Connexions mTLS courantes
Cisco Unified CM/PME	Tomcat/Tomcat-ECDSA	LDAP, Filebeat, Logstash, SIP OAuth sur MRA, Remote Syslog
	CallManager/CallManager-ECDSA	Trunks SIP, connexions entre nœuds et entre clusters
Cisco Unity Connection	Tomcat/Tomcat-ECDSA	Proxy SIP, liaisons SIP
Messagerie instantanée et présence Cisco	Tomcat/Tomcat-ECDSA	—
	tasse/Tasse-ECDSA	SIP sécurisé avec CUCM, clients tiers, proxy SIP
	cup-xmpp/CUP-XMPP-eCDSA	Fédération XMPP
Cisco Emergency Responder	Tomcat/Tomcat-ECDSA	—
Cisco Expressway	Certificat de serveur	Mobile et Remote Access (MRA)

Les certificats ne sont pas concernés

Tous les certificats restants dans Dedicated Instance sont autosignés. Pour plus d' informations, consultez la section Gestion des certificats des instances dédiées.

Pour faire face au changement de politique de Chrome et maintenir la fonctionnalité mTLS sans interruption, Cisco prendra les mesures suivantes :

• À compter du ^1er juin 2026, Cisco fera passer l'autorité de certification racine publique utilisée pour signer les certificats d'application UC des instances dédiées, d'IdenTrust Commercial Root CA 1 à IdenTrust Public Sector Root CA 1 pour tous les renouvellements de certificats.

  Le processus de renouvellement des certificats reste le même, et le Control Hub Alerts Center informe les clients par le biais d'une alerte « Maintenance et panne » lorsque le renouvellement est prévu. Pour plus d'informations, consultez la section Alertes de maintenance.

• Les certificats continueront d'inclure à la fois des unités d'authentification du serveur et du client.

Toutes les applications ou services tiers de l'environnement client connectant des applications UC dans une instance dédiée via des connexions TLS ou mTLS doivent utiliser la même chaîne de certificats que les applications UC dans une instance dédiée. Si le Trust Store des systèmes ou des applications du client n'inclut pas déjà les autorités de certification IdenTrust requises, le nouveau certificat racine doit être importé pour éviter les échecs de connexion TLS/MTLS.

1. Auditez les connexions mTLS actuelles
   1. Identifiez les applications, les services tiers ou les intégrations qui se connectent aux applications UC dans une instance dédiée via TLS ou mTLS.
   2. Vérifiez si ces applications font confiance à la nouvelle autorité de certification racine publique : IdenTrust Public Sector Root CA 1.
2. Ajouter la nouvelle autorité de certification racine publique (si nécessaire)
   1. Si l'identifiant IdentiTrust Public Sector Root CA 1 n'est pas déjà approuvé dans l'application client ou dans le System Trust Store, il faut l'ajouter.
   2. Le même fichier peut être téléchargé sur les liens suivants :

      Root CA : IdentiTrust Public Sector Root CA 1

      Autre page de téléchargement : IdenTrust Support Downloads

      Émetteur/sous-autorité de certification : Serveur du secteur public IdenTrust CA 1.

   Pour la plupart des applications, il suffit de faire confiance à l'autorité de certification racine si le serveur présente la chaîne complète. Il est avantageux d'inclure la certification d'émission et de sous-certification pour les demandes qui nécessitent l'importation séparée du certificat intermédiaire.

La racine CA 1 d'IdenTrust Public Sector est approuvée par défaut dans les Trust Stores standard pour les systèmes d'exploitation et les plateformes suivants :

• Microsoft Windows
• MacOS
• iOS/iPadOS
• Android

Par conséquent, le client n'est tenu que de valider les boutiques de confiance pour ces plateformes afin de confirmer que le nouveau certificat racine de la nouvelle autorité de certification publique est déjà répertorié. Cela s'applique aux endpoints/clients ou aux systèmes tiers qui utilisent les boutiques de confiance par défaut sur ces plateformes. Les instructions pour mettre à jour le Trust Store sur chaque plateforme sont fournies dans les sections ci-dessous. La responsabilité de ces mises à jour incombe au client ou au partenaire ; les liens et les étapes ci-dessous font référence à des articles en ligne publiés par les fournisseurs de plateformes concernés, et Cisco fournit une assistance dans la mesure du possible. Pour plus de précisions, vous devez travailler directement avec les fournisseurs de plateformes concernés.

Note sur l'Android Trust Store

L'IdenTrust Public Sector Root CA 1 est inclus dans la boutique CA du système Android et est approuvé par défaut sur les versions Android actuellement prises en charge. Android ne fournit pas de mappage public spécifique à une version pour les dates d'introduction de chaque certificat racine. La confiance est gérée par le biais de la boutique CA du système Android et diffusée via les mises à jour du système d'exploitation et du système Google Play.

Aucune action du client n'est requise, sauf si la boutique de confiance du système Android a été explicitement modifiée par la politique des appareils, les contrôles de gestion de l'entreprise ou des restrictions de confiance spécifiques aux applications.

L'identifiant IdentiTrust Public Sector Root CA 1 n'est pas inclus dans le Root Store de Google Chrome.

Pour s'assurer que Google Chrome fait confiance aux certificats émis en vertu de cette autorité de certification racine, les clients doivent s'assurer que le certificat racine est explicitement approuvé au niveau du système d'exploitation aux emplacements utilisés par Chrome pour les décisions de confiance locales.

Windows : configuration de confiance requise

Pour que Google Chrome fasse confiance à l'autorité de certification racine sur Windows, l'autorité de certification racine 1 d'IdenTrust pour le secteur public doit être importée dans l'un des emplacements suivants :

• Ordinateur local → Autorités de certification root fiables

  (Recommandé pour les systèmes gérés par les entreprises)

ou

• Utilisateur actuel → Autorités de certification Root fiables

  (Pour une confiance au niveau de l'utilisateur)

Les certificats importés à l'aide de l'assistant d'importation de certificats Windows vers ces sites (y compris via la politique de groupe) sont approuvés par Google Chrome.

Chrome n'approuve pas automatiquement les certificats root qui n'existent que dans la version tierce de Windows, sauf s'ils sont importés explicitement comme décrit ci-dessus.

Mac OS : configuration de confiance requise

Pour que Google Chrome fasse confiance à l'autorité de certification racine sur macOS, l'autorité de certification racine 1 d'IdenTrust pour le secteur public doit être ajoutée au trousseau macOS et explicitement approuvée :

1. Importez le certificat dans le porte-clés du système (recommandé) ou dans le trousseau de connexion

2. Ouvrez le certificat et définissez :

   • Lorsque vous utilisez ce certificat : Always Trust

     (ou au minimum, SSL : Always Trust)

Une fois approuvé au niveau du système ou de l'utilisateur, Google Chrome considérera le certificat comme étant fiable.

Les administrateurs peuvent vérifier quels certificats de plateforme sont approuvés par Chrome en accédant à : chrome : //certificate-manager/localcerts/platformcerts

Pour plus d'informations, consultez la FAQ de Google.

Les intégrations tierces nécessitent une validation par le client principal.

Pour toutes les applications ou services tiers qui établissent des connexions TLS/mTLS avec des applications UC d'instances dédiées, les clients doivent suivre les actions mentionnées dans les modifications des certificats publics de certification ayant un impact sur les instances dédiées.

Vous devrez collaborer directement avec votre fournisseur tiers ou votre administrateur informatique si les mises à jour du Trust Store sont nécessaires. Les modifications apportées aux boutiques de confiance tierces ou aux comportements de validation des certificats ne relèvent pas de la responsabilité de Cisco, et Cisco ne peut pas vous aider à configurer ou à résoudre les problèmes liés aux certificats tiers.

Les clients peuvent valider la nouvelle autorité de certification Public Root en utilisant le certificat de test IdenTrust.

Si la page s'ouvre correctement, c'est que votre environnement fait confiance à la racine CA 1 d'IdenTrust Public Sector.

Si vous avez des questions concernant ce changement, la politique du navigateur Google Chrome ou les mises à jour des certificats dans Dedicated Instance, ouvrez une demande de service dans Control Hub, dans la section Cycle de vie de l'application UC.

Les clients d'UCM Cloud (UCMC) qui sont propriétaires de leur domaine et gèrent le renouvellement de leurs certificats d'applications UC et qui n'ont pas délégué l'autorité de domaine à Cisco pour la signature de certificats d' applications UC seront tenus de travailler directement avec les autorités de certification publiques de leur choix pour faire face à ce changement. 

Ces clients doivent également se conformer aux recommandations du produit d'application UC applicable (produits d'appel sur site Cisco et Cisco Expressway) concernant l'utilisation des certificats et les mesures correctives liées à la prochaine autorité de certification publique et aux modifications de la politique des navigateurs. Pour plus d'informations, voir Rôles et responsabilités. 

Cisco continuera à fournir des mises à jour au fur et à mesure que la prise en charge des applications UC pour des certificats serveur et client distincts sera disponible. Consultez ce document pour les dernières mises à jour.

Changements apportés au certificat EKU : mesures que les clients de Cisco On-Premise Collaboration DOIVENT PRENDRE DÈS MAINTENANT