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 l'émission de certificats TLS publics et de décrire les mesures que Cisco prendra pour assurer 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 (AC) incluses dans le programme Google Chrome Trust cesseront de signer les certificats qui incluent l'utilisation étendue de la clé (EKU) d'authentification du client (clientAuth).

À compter du^{15 mars} 2027 , Google appliquera une politique exigeant que les autorités de certification racine publiques du Chrome Root Store émettent des certificats contenant uniquement l'EKU d'authentification du serveur (serverAuth). En conséquence, les autorités de certification racine publiques du Chrome Root Store ne seront plus autorisées à émettre des certificats combinant à la fois l'authentification du serveur et l'authentification du client dans un seul certificat.

Les applications UC d'instance dédiée utilisent actuellement des certificats qui incluent à la fois l'authentification du serveur et l'authentification du client dans un seul certificat pour établir la confiance pour les connexions mTLS. La prise en charge de certificats serveur et client distincts devrait être introduite avec la version v15SU5 de l'application UC, prévue pour plus tard en 2026.

Actuellement, l'instance dédiée utilise l'autorité de certification racine commerciale IdenTrust 1, qui fait partie du Google Chrome Root Store, pour signer ces certificats. Cependant, en raison du prochain changement de politique de Chrome, cette CA ne sera plus autorisée à émettre des certificats contenant les deux EKU dans un seul certificat à partir du^1erfé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 communes
Cisco Unified CM / PME	Matou / Tomcat-ECDSA	LDAP, Filebeat, Logstash, SIP OAuth sur MRA, Syslog distant
	Gestionnaire d'appels / Gestionnaire d'appels-ECDSA	Liaisons SIP, connexions inter-nœuds et inter-clusters
Connexion Cisco Unity	Matou / Tomcat-ECDSA	Proxy SIP, jonctions SIP
MI Cisco et Presence	Matou / Tomcat-ECDSA	—
	tasse / coupe-ECDSA	Sécurisation du protocole SIP avec CUCM, clients tiers et proxy SIP
	tasse-xmpp / cup-xmpp-ECDSA	Fédération XMPP
Cisco Emergency Responder	Matou / Tomcat-ECDSA	—
Cisco Expressway	Certificat du serveur	Périphériques Remote Access mobiles (MRA)

Les certificats ne sont pas concernés

Tous les certificats restants dans l'instance dédiée sont auto-signés. Pour plus d'informations, voir Gestion des certificats d'instance dédiée.

Pour remédier au changement de politique de Chrome et maintenir la fonctionnalité mTLS ininterrompue, Cisco prendra les mesures suivantes :

• À compter du 1er juin, 2026, Cisco remplacera l'autorité de certification racine publique utilisée pour la signature des certificats d'application UC d'instance dédiée IdenTrust Commercial Root CA 1 par IdenTrust Public Sector Root CA 1 pour tous les renouvellements de certificats.

  Le processus de renouvellement des certificats reste le même, et le Centre d'alertes Control Hub notifie les clients via l'alerte «  Maintenance et panne » lorsque le renouvellement est programmé. Pour plus d'informations, voir Alertes de maintenance.

• Les certificats continueront d'inclure les EKU d'authentification serveur et client.

Toute application ou tout service tiers dans l'environnement client se connectant à des applications UC dans une instance dédiée à l'aide de connexions TLS ou mTLS doit utiliser la même chaîne de certificats que les applications UC dans l'instance dédiée. Si le magasin de certificats de confiance des systèmes ou applications du client n'inclut pas déjà les autorités de certification IdenTrust requises, le nouveau certificat racine doit être importé pour éviter tout problème. TLS/mTLS Échecs de connexion.

1. Audit des connexions mTLS actuelles
   1. Identifiez les applications, les services tiers ou les intégrations qui se connectent aux applications UC dans l'instance dédiée en utilisant 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' IdenTrust Public Sector Root CA 1 n'est pas déjà approuvé dans l'application cliente ou le magasin de confiance du système, il doit être ajouté.
   2. Le même fichier peut être téléchargé à partir des liens suivants :

      Autorité de certification racine: IdenTrust Public Sector Root CA 1

      Page de téléchargement alternative: Téléchargements du support IdenTrust

      Issuing/Sub CA: Serveur du secteur public IdenTrust CA 1.

   Pour la plupart des applications, il est suffisant de faire confiance à l'autorité de certification racine si le serveur présente la chaîne complète. Le Issuing/Sub L'inclusion d'une autorité de certification (CA) est avantageuse pour les applications qui nécessitent l'importation séparée du certificat intermédiaire.

L'autorité de certification racine du secteur public IdenTrust 1 est approuvée par défaut dans les magasins de certificats de confiance standard pour les systèmes d'exploitation et plateformes suivants :

• Microsoft Windows
• macOS
• iOS / iPadOS
• Android

Par conséquent, aucune action du client n'est requise pour les terminaux ou les systèmes utilisant des magasins de certificats de confiance par défaut sur ces plateformes, sauf si le magasin de certificats de confiance a été explicitement modifié ou restreint par la politique du client.

Note du magasin de confiance Android

L'autorité de certification racine du secteur public IdenTrust 1 est incluse dans le magasin d'autorités de certification du système Android et est approuvée par défaut sur les versions Android actuellement prises en charge. Android ne fournit pas de table de correspondance publique et spécifique à chaque version pour les dates d'introduction des certificats racine. La confiance est gérée par le biais du magasin d'autorités de certification du système Android et distribuée via les mises à jour du système d'exploitation et les mises à jour du système Google Play.

Aucune action du client n'est requise, sauf si le magasin de clés de confiance du système Android a été explicitement modifié par la politique de l'appareil, les contrôles de gestion d'entreprise ou les restrictions de confiance spécifiques à l'application.

L'autorité de certification racine IdenTrust Public Sector 1 n'est pas incluse dans le Google Chrome Root Store.

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

Windows – configuration de confiance requise

Pour garantir que l'autorité de certification racine est approuvée par Google Chrome sous Windows, l'autorité de certification racine du secteur public IdenTrust 1 doit être importée dans l'un des emplacements suivants :

• Ordinateur local → Autorités de certification racine de confiance

  (Recommandé pour les systèmes gérés en entreprise)

ou

• Utilisateur actuel → Autorités de certification racine de confiance

  (Pour la confiance au niveau de l'utilisateur)

Les certificats importés à l'aide de l'Assistant d'importation de certificats Windows dans ces emplacements (y compris via la stratégie de groupe) sont considérés comme fiables par Google Chrome.

Les certificats racine qui existent uniquement dans le répertoire des certificats tiers de Windows ne sont pas automatiquement approuvés par Chrome, sauf s'ils sont explicitement importés comme décrit ci-dessus.

Mac OS – configuration de confiance requise

Pour garantir que l'autorité de certification racine est approuvée par Google Chrome sur macOS, l'autorité de certification racine du secteur public IdenTrust 1 doit être ajoutée au Trousseau d'accès macOS et explicitement approuvée :

1. Importez le certificat dans le Trousseau système (recommandé) ou le Trousseau de connexion.

2. Ouvrez le certificat et configurez :

   • Lors de l'utilisation de ce certificat : Ayez toujours confiance

     (ou au minimum, SSL : Toujours faire confiance)

Une fois approuvé au niveau du système ou de l'utilisateur, Google Chrome considérera le certificat comme 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 du client principal.

Pour toute application ou tout service tiers qui établit TLS/mTLS Pour les connexions avec les applications UC d'instance dédiée, les clients doivent suivre les actions mentionnées dans Modifications du certificat d'autorité de certification publique ayant un impact sur l'instance dédiée.

Vous devrez collaborer directement avec votre fournisseur tiers ou votre administrateur informatique si des mises à jour du magasin de certificats de confiance sont nécessaires. Les modifications apportées aux magasins de certificats de confiance tiers ou aux comportements de validation des certificats ne relèvent pas de la responsabilité de Cisco, et Cisco ne peut pas apporter d'assistance concernant les configurations de confiance des certificats tiers ou le dépannage.

Les clients peuvent valider la connectivité et la confiance pour la nouvelle autorité de certification racine publique en accédant au certificat de test IdenTrust suivant .

Si ce certificat s'ouvre avec succès sans avertissement de confiance, l'autorité de certification racine du secteur public IdenTrust 1 est déjà approuvée dans l'environnement.

Si vous avez des questions concernant cette modification, la politique du navigateur Google Chrome ou les mises à jour de certificats dans l'instance dédiée, ouvrez une demande de service dans Control Hub sous Cycle de vie de l'application UC.

Les clients UCM Cloud (UCMC) qui possèdent leur domaine et gèrent eux-mêmes le renouvellement de leurs certificats d'application UC et qui n'ont pas délégué l'autorité de domaine à Cisco pour la signature des certificats d'application UC seront responsables de travailler directement avec les autorités de certification publiques qu'ils ont choisies pour faire face à ce changement.

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

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

Modifications apportées au certificat EKU : Actions que les clients de Cisco On-premises Collaboration DOIVENT entreprendre dès maintenant