Gracias por sus comentarios.

Esto es para informarle sobre un próximo cambio en la política del navegador Google Chrome que afecta la emisión de certificados TLS públicos y para describir las acciones que Cisco tomará para garantizar el soporte continuo para las conexiones TLS mutuas ( MTLS) en entornos de instancia Cisco Webex Calling dedicada y UCM Cloud.

^{A partir del 1 de febrero de 2027, las Autoridades de Certificación Pública (CA) incluidas en el programa Google Chrome Trust dejarán de firmar certificados que incluyan el uso extendido de claves (EKU) de autenticación de cliente (ClientAuth).}

A partir ^del 15 de marzo de 2027, Google hará cumplir una política que requiere que las CA raíz pública en Chrome Root Store emitan certificados que contengan solo la EKU de autenticación de servidor (ServerAuth). Como resultado, las CA raíz públicas en Chrome Root Store ya no podrán emitir certificados que combinen las EKU de autenticación de servidor y autenticación de cliente en un solo certificado.

Las aplicaciones UC de instancia dedicada utilizan actualmente certificados que incluyen tanto la autenticación de servidor como las de autenticación de cliente dentro de un único certificado para establecer la confianza para las conexiones MTLs. El soporte para certificados de servidor y cliente separados ahora está disponible con la versión de aplicación UC V15SU5.

Actualmente, la instancia dedicada utiliza IdenTrust Commercial Root CA 1, parte de Google Chrome Root Store, para firmar estos certificados. Sin embargo, debido al próximo cambio en la política de Chrome, esta CA ya no podrá emitir certificados que contengan ambas EKU en un solo certificado a partir del 1 de febrero de ²⁰²⁷.

Certificados afectados

Los siguientes certificados de aplicación UC se firman mediante una CA raíz pública y se utilizan comúnmente para conexiones MTLs:

Aplicación UC	Tipo de certificado	Conexiones MTLs comunes
Cisco Unified CM/PYME	Tomcat/Tomcat-ECDSA	LDAP, Filebeat, Logstash, SIP OAuth sobre MRA, Syslog remoto
	Gerente de llamadas/Administrador de llamadas - ECDSA	Trunks SIP, conexiones entre nodos e interclústeres
Cisco Unity Connection	Tomcat/Tomcat-ECDSA	Proxy SIP, troncales SIP
Cisco IM y presencia	Tomcat/Tomcat-ECDSA	—
	taza/Taza ECDSA	SIP seguro con CUCM, clientes de terceros, proxy SIP
	cup-xmpp/Cup-XMPP-ECDSA	Federación XMPP
Cisco Emergency Responder	Tomcat/Tomcat-ECDSA	—
Cisco Expressway	Certificado de servidor	Móvil y Remote Access (MRA)

Certificados no afectados

Todos los certificados restantes en la Instancia Dedicada son autofirmados. Para obtener información adicional, consulte Administración de certificados de instancia dedicada.

Para abordar el cambio de política de Chrome y mantener la funcionalidad MTL ininterrumpida, Cisco tomará las siguientes medidas:

• ^{A partir del 1 de junio de 2026, Cisco cambiará la CA raíz pública utilizada para firmar certificados de aplicación UC de instancia dedicada de IdenTrust Commercial Root CA 1 a IdenTrust Public Sector Root CA 1 para todas las renovaciones de certificados.}

  El proceso de renovación del certificado sigue siendo el mismo, y el Centro de alertas de Control Hub notifica a los clientes a través de la alerta "Mantenimiento e interrupciones" cuando se programa la renovación. Para obtener más información, consulte Alertas de mantenimiento.

• Los certificados continuarán incluyendo tanto las EKU de autenticación del servidor como del cliente.

Cualquier aplicación o servicio de terceros en el entorno del cliente que conecte aplicaciones UC en una instancia dedicada mediante conexiones TLS o MTLS debe utilizar la misma cadena de certificados que las aplicaciones UC en una instancia dedicada. Si el almacén de confianza de sistemas o aplicaciones del cliente aún no incluye las autoridades certificadoras de IdenTrust requeridas, se debe importar el nuevo certificado raíz para evitar errores de conexión TLS/MTLS.

1. Auditar las conexiones MTLs actuales
   1. Identifique aplicaciones, servicios de terceros o integraciones que se conectan a las aplicaciones UC en una instancia dedicada mediante TLS o MTLS.
   2. Verifique si esas aplicaciones confían en la nueva CA de raíz pública: IdenTrust Public Sector Root CA 1.
2. Agregue la nueva CA raíz pública (si es necesario)
   1. Si la CA 1 raíz del sector público de IdenTrust aún no es de confianza en la aplicación del cliente o en el almacén de confianza del sistema, debe agregarse.
   2. Lo mismo se puede descargar de los siguientes enlaces:

      CA raíz: IdenTrust Raíz CA 1 del sector público

      Página de descarga alternativa: Descargas de soporte de IdenTrust

      Emisor/Sub CA: IdenTrust Public Sector Server CA 1.

   Para la mayoría de las aplicaciones, confiar en la CA raíz es suficiente si el servidor presenta la cadena completa. Es beneficioso incluir la CA de emisión/sub para las aplicaciones que requieren que el certificado intermedio se importe por separado.

IdenTrust Public Sector Root CA 1 es confiable de manera predeterminada en los almacenes de confianza estándar para los siguientes sistemas operativos y plataformas:

• Microsoft Windows
• macOS
• iOS /iPadOS
• Android

Como resultado, el cliente solo debe validar los almacenes de confianza para estas plataformas para confirmar que el nuevo certificado raíz de la CA pública ya está en la lista. Esto se aplica a los endpoints/clientes o sistemas de terceros que utilizan los almacenes de confianza predeterminados en estas plataformas. Las instrucciones para actualizar la tienda de confianza en cada plataforma se proporcionan en las secciones siguientes. La responsabilidad de realizar estas actualizaciones recae en el Cliente o Partner; los enlaces y pasos a continuación hacen referencia a artículos en línea de los respectivos proveedores de la plataforma, y Cisco brinda asistencia con el mejor esfuerzo posible. Para mayor aclaración, debe trabajar directamente con los respectivos proveedores de plataformas.

Nota de la tienda de confianza de Android

La CA 1 raíz del sector público de IdenTrust se incluye en la tienda CA del sistema Android y es de confianza de forma predeterminada en las versiones de Android compatibles actualmente. Android no proporciona una asignación pública específica de versión para las fechas de introducción de certificados raíz individuales. La confianza se administra a través de la tienda CA del sistema Android y se distribuye a través de actualizaciones del sistema operativo y actualizaciones del sistema de Google Play.

No se requiere ninguna acción del cliente a menos que el almacén de confianza del sistema Android haya sido modificado explícitamente por la política de dispositivos, los controles de administración empresarial o las restricciones de confianza específicas de la aplicación.

La Root CA 1 del sector público de IdenTrust no está incluida en la tienda raíz de Google Chrome.

Para asegurarse de que Google Chrome confía en los certificados emitidos bajo esta CA raíz, los clientes deben asegurarse de que el certificado raíz sea de confianza explícita a nivel del sistema operativo en las ubicaciones que Chrome consume para las decisiones de confianza locales.

Windows: configuración de confianza requerida

Para asegurarse de que Google Chrome confía en la CA raíz en Windows, la CA raíz 1 de IdenTrust Public Sector debe importarse en una de las siguientes ubicaciones:

• Computadora local → Autoridades de certificación raíz de confianza

  (Recomendado para sistemas administrados por la empresa)

o

• Usuario actual → Autoridades de certificación raíz de confianza

  (Para la confianza a nivel de usuario)

Google Chrome confía en los certificados importados mediante el Asistente para importación de certificados de Windows en estas ubicaciones (incluso a través de la directiva de grupo).

Chrome no confía automáticamente en los certificados raíz que existen solo en el tercero de Windows, a menos que se importen explícitamente como se describe anteriormente.

Mac OS: configuración de confianza requerida

Para asegurarse de que Google Chrome confía en la CA raíz en macOS, la CA raíz 1 de IdenTrust Public Sector debe agregarse al llavero de macOS y debe ser de confianza explícita:

1. Importe el certificado en el llavero del sistema (recomendado) o el llavero de inicio de sesión

2. Abra el certificado y configure:

   • Cuando utilice este certificado: Siempre confíe

     (o como mínimo, SSL: Siempre confíe)

Una vez que se confía en el sistema o a nivel de usuario, Google Chrome respetará el certificado como de confianza.

Los administradores pueden verificar en qué certificados de plataforma confía Chrome navegando a: chrome: //certificate-manager/localcerts/platformcerts

Para obtener más información, consulte Preguntas frecuentes de Google.

Las integraciones de terceros requieren la validación principal del cliente.

Para cualquier aplicación o servicio de terceros que establezcan conexiones TLS/MTL con aplicaciones UC de instancia dedicada, los clientes deben seguir las acciones mencionadas en los cambios del certificado de CA pública que afectan a la instancia dedicada.

Tendrá que colaborar directamente con su proveedor externo o administrador de TI si se requieren las actualizaciones de la tienda de confianza. Las modificaciones a los almacenes de confianza de terceros o los comportamientos de validación de certificados están fuera de las responsabilidades de Cisco, y Cisco no puede ayudar con las configuraciones de confianza de certificados de terceros o la solución de problemas.

Los clientes pueden validar la nueva CA raíz pública mediante el certificado de prueba IdenTrust.

Si la página se abre correctamente, IdenTrust Public Sector Root CA 1 es de confianza en su entorno.

Si tiene preguntas sobre este cambio, la política del navegador Google Chrome o las actualizaciones de certificados en una instancia dedicada, abra una solicitud de servicio en Control Hub bajo el ciclo de vida de la aplicación UC.

Los clientes de UCM Cloud (UCMC) que sean propietarios de su dominio y administren sus propias renovaciones de certificados de aplicaciones UC y que no hayan delegado autoridad de dominio a Cisco para firmar certificados de aplicación UC serán responsables de trabajar directamente con las autoridades de certificación públicas elegidas para abordar este cambio. 

Estos clientes también deben alinearse con el producto de aplicación UC (productos de llamadas locales de Cisco y Cisco Expressway) recomendaciones sobre el uso de certificados y la corrección relacionadas con los próximos cambios en la CA pública y la política del navegador. Para obtener más información, consulte Roles y responsabilidades. 

Cisco continuará proporcionando actualizaciones a medida que esté disponible el soporte de aplicaciones UC para certificados de cliente y servidor separados. Consulte este documento para obtener las últimas actualizaciones.

Cambios en el certificado EKU: Acciones que los clientes de Cisco On-Premisse Collaboration DEBEN TOMAR AHORA