Obrigado pelos seus comentários.

Este comunicado tem como objetivo informá-lo sobre uma futura alteração na política do navegador Google Chrome que impacta a emissão de certificados TLS públicos e descrever as ações que a Cisco tomará para garantir o suporte contínuo para conexões TLS mútuas (mTLS) em ambientes Cisco Webex Calling Dedicated Instance e UCM Cloud.

A partir de^{1º de fevereiro de} 2027 , as Autoridades de Certificação (ACs) públicas incluídas no programa Google Chrome Trust deixarão de assinar certificados que incluam o uso estendido de chave (EKU) de autenticação de cliente (clientAuth).

A partir de^{15 de março} de 2027, o Google implementará uma política que exige que as Autoridades Certificadoras Raiz Públicas no Chrome Root Store emitam certificados contendo apenas a EKU de Autenticação de Servidor (serverAuth). Como resultado, as Autoridades Certificadoras Raiz Públicas no Chrome Root Store não poderão mais emitir certificados que combinem EKUs de Autenticação de Servidor e Autenticação de Cliente em um único certificado.

Atualmente, as aplicações de UC de instância dedicada utilizam certificados que incluem EKUs de autenticação de servidor e de cliente em um único certificado para estabelecer confiança nas conexões mTLS. O suporte para certificados separados para servidor e cliente deverá ser introduzido na versão v15SU5 do aplicativo UC, prevista para o final de 2026.

Atualmente, a Instância Dedicada utiliza a Autoridade Certificadora Raiz Comercial IdenTrust 1, que faz parte do Repositório Raiz do Google Chrome, para assinar esses certificados. No entanto, devido à próxima alteração na política do Chrome, esta CA não terá mais permissão para emitir certificados contendo ambos os EKUs em um único certificado a partir de^{1º de fevereiro}de 2027.

Certificados afetados

Os seguintes certificados de aplicação UC são assinados usando uma Autoridade Certificadora Raiz Pública e são comumente usados para conexões mTLS:

candidatura à UC	Tipo de certificado	Conexões mTLS comuns
Cisco Unified CM / PME	Gato / Tomcat-ECDSA	LDAP, Filebeat, Logstash, SIP OAuth sobre MRA, Syslog remoto
	CallManager / CallManager-ECDSA	Troncos SIP, conexões entre nós e entre clusters
Cisco Unity Connection	Gato / Tomcat-ECDSA	Proxy SIP, Troncos SIP
Cisco IM e Presence	Gato / Tomcat-ECDSA	—
	xícara / copo-ECDSA	SIP seguro com CUCM, clientes de terceiros e proxy SIP.
	copo-xmp / copo-xmpp-ECDSA	Federação XMPP
Cisco Emergency Responder	Gato / Tomcat-ECDSA	—
Cisco Expressway	Certificado do servidor	Celular e Remote Access (MRA)

Os certificados não foram afetados.

Todos os certificados restantes na Instância Dedicada são autoassinados. Para obter informações adicionais, consulte Gerenciamento de certificados de instância dedicada.

Para lidar com a alteração na política do Chrome e manter a funcionalidade mTLS ininterrupta, a Cisco tomará as seguintes medidas:

• A partir de^{1º de junho}de 2026, a Cisco mudará a Autoridade de Certificação Raiz Pública usada para assinarcertificados de aplicativos de Instância Dedicada UC de IdenTrust Commercial Root CA 1 para IdenTrust Public Sector Root CA 1 para todas as renovações de certificado.

  O processo de renovação do certificado permanece o mesmo, e o Centro de Alertas do Control Hub notifica os clientes por meio do alerta "Manutenção e Interrupção" quando a renovação está agendada. Para obter mais informações, consulte Alertas de manutenção.

• Os certificados continuarão a incluir EKUs de autenticação de servidor e de cliente.

Quaisquer aplicativos ou serviços de terceiros no ambiente do cliente que se conectem a aplicativos de Comunicações Unificadas (UC) em uma Instância Dedicada usando conexões TLS ou mTLS devem utilizar a mesma cadeia de certificados que os aplicativos de UC na Instância Dedicada. Se o repositório de certificados confiáveis dos sistemas ou aplicativos do cliente ainda não incluir as autoridades de certificação IdenTrust necessárias, o novo certificado raiz deverá ser importado para evitar problemas. TLS/mTLS falhas de conexão.

1. Auditar conexões mTLS atuais
   1. Identificar aplicativos, serviços de terceiros ou integrações que se conectam aos Aplicativos de Comunicações Unificadas na Instância Dedicada usando TLS ou mTLS.
   2. Verifique se esses aplicativos confiam na nova Autoridade Certificadora Raiz Pública: IdenTrust Autoridade Certificadora Raiz do Setor Público 1.
2. Adicione a nova Autoridade Certificadora Raiz Pública (se necessário)
   1. Se o IdenTrust Public Sector Root CA 1 ainda não for confiável no aplicativo do cliente ou no armazenamento de confiança do sistema, ele deverá ser adicionado.
   2. O mesmo pode ser baixado nos seguintes links:

      CA raiz: IdenTrust de autoridade de certificação raiz do setor público 1

      Página de download alternativa: Downloads de suporte do IdenTrust

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

   Para a maioria das aplicações, confiar na Autoridade Certificadora Raiz é suficiente se o servidor apresentar a cadeia completa. O Issuing/Sub A inclusão da Autoridade Certificadora (CA) é benéfica para aplicações que exigem a importação separada do certificado intermediário.

A Autoridade Certificadora Raiz do Setor Público IdenTrust 1 é considerada confiável por padrão nos repositórios de certificados confiáveis padrão para os seguintes sistemas operacionais e plataformas:

• Microsoft Windows
• macOS
• iOS / iPadOS
• Android

Consequentemente, nenhuma ação do cliente é necessária para endpoints ou sistemas que utilizam armazenamentos de confiança padrão nessas plataformas, a menos que o armazenamento de confiança tenha sido explicitamente modificado ou restringido pela política do cliente.

Nota sobre a loja de confiança do Android

A Autoridade Certificadora Raiz do Setor Público IdenTrust 1 está incluída no repositório de Autoridades Certificadoras do sistema Android e é considerada confiável por padrão nas versões do Android atualmente suportadas. O Android não fornece um mapeamento público e específico da versão para as datas de introdução de certificados raiz individuais. A confiança é gerenciada por meio do repositório de autoridades certificadoras (CA) do sistema Android e distribuída via atualizações do sistema operacional e atualizações do Google Play.

Nenhuma ação do cliente é necessária, a menos que o repositório de confiança do sistema Android tenha sido explicitamente modificado por política do dispositivo, controles de gerenciamento corporativo ou restrições de confiança específicas do aplicativo.

A Autoridade Certificadora Raiz do Setor Público IdenTrust 1 não está incluída no Repositório de Autoridades Certificadoras Raiz do Google Chrome.

Para garantir que o Google Chrome confie em certificados emitidos por esta Autoridade Certificadora raiz, os clientes devem assegurar que o certificado raiz seja explicitamente confiável no nível do sistema operacional, nos locais que o Chrome utiliza para decisões de confiança local.

Windows – configuração de confiança necessária

Para garantir que a Autoridade Certificadora raiz seja confiável para o Google Chrome no Windows, a Autoridade Certificadora Raiz do Setor Público IdenTrust 1 deve ser importada para um dos seguintes locais:

• Computador local → Autoridades de Certificação Raiz Confiáveis

  (Recomendado para sistemas gerenciados pela empresa)

ou

• Usuário atual → Autoridades de Certificação Raiz Confiáveis

  (Para confiança ao nível do utilizador)

Os certificados importados para esses locais usando o Assistente de Importação de Certificados do Windows (inclusive via Política de Grupo) são confiáveis para o Google Chrome.

Os certificados raiz que existem apenas no repositório de terceiros do Windows não são automaticamente considerados confiáveis pelo Chrome, a menos que sejam importados explicitamente, conforme descrito acima.

macOS – configuração de confiança necessária

Para garantir que a Autoridade Certificadora raiz seja confiável para o Google Chrome no macOS, a Autoridade Certificadora Raiz do Setor Público IdenTrust 1 deve ser adicionada ao Acesso às Chaves do macOS e explicitamente considerada confiável:

1. Importe o certificado para o Keychain do Sistema (recomendado) ou para o Keychain de Login.

2. Abra o certificado e configure:

   • Ao usar este certificado: Sempre confie

     (ou, no mínimo, SSL: Confie sempre)

Uma vez que o sistema ou o usuário considere o certificado confiável, o Google Chrome o reconhecerá como tal.

Os administradores podem verificar quais certificados de plataforma são confiáveis para o Chrome acessando o seguinte endereço: chrome://certificate-manager/localcerts/platformcerts

Para obter mais informações, consulte Perguntas frequentes do Google.

As integrações com terceiros exigem validação primária do cliente.

Para quaisquer aplicativos ou serviços de terceiros que estabeleçam TLS/mTLS conexões com aplicativos UC de instância dedicada, os clientes devem seguir as ações mencionadas em Alterações de certificado CA público que afetam a instância dedicada.

Você precisará colaborar diretamente com seu fornecedor terceirizado ou administrador de TI caso sejam necessárias atualizações no repositório de certificados confiáveis. Modificações em repositórios de confiança de terceiros ou comportamentos de validação de certificados estão fora da responsabilidade da Cisco, e a Cisco não pode auxiliar com configurações de confiança de certificados de terceiros ou solução de problemas.

Os clientes podem validar a conectividade e a confiança para a nova Autoridade de Certificação Raiz Pública acessando o seguinte certificado de teste IdenTrust .

Se este certificado for aberto com sucesso, sem avisos de confiança, a Autoridade Certificadora Raiz do Setor Público IdenTrust 1 já é considerada confiável no ambiente.

Se você tiver dúvidas sobre essa alteração, a política do navegador Google Chrome ou as atualizações de certificado na Instância Dedicada, abra uma Solicitação de Serviço no Control Hub em Ciclo de vida do aplicativo UC.

Os clientes do UCM Cloud (UCMC) que possuem seu próprio domínio e gerenciam as renovações de seus certificados de aplicativos de Comunicações Unificadas (UC) e que não delegaram a autoridade de domínio à Cisco para assinatura de certificados de aplicativos de UC serão responsáveis por trabalhar diretamente com as Autoridades de Certificação Públicas escolhidas para lidar com essa mudança.

Esses clientes também devem estar alinhados com as recomendações aplicáveis do produto de aplicação UC ( Produtos de chamadas locais da Cisco e Cisco Expressway) em relação ao uso de certificados e à correção relacionada às próximas alterações nas políticas de CA pública e navegador. Para obter mais informações, consulte Funções e Responsabilidades.

A Cisco continuará a fornecer atualizações à medida que o suporte para certificados separados de servidor e cliente em aplicativos de Comunicações Unificadas (UC) estiver disponível. Consulte este documento para obter as atualizações mais recentes.

Alterações no Certificado EKU: Ações que os clientes do Cisco On-premises Collaboration DEVEM TOMAR AGORA