O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve as alterações da política do programa raiz do Chrome no Cisco Expressway e o encerramento do EKU de autenticação de cliente em certificados de CA públicos após 26/6.
Os certificados digitais são credenciais eletrônicas emitidas por Autoridades de Certificação (CAs) confiáveis que protegem a comunicação entre servidores e clientes, garantindo a autenticação, a integridade dos dados e a confidencialidade. Estes certificados contêm campos de Uso Estendido de Chave (EKU) que definem sua finalidade:
Tradicionalmente, um único certificado pode conter EKUs de Autenticação de Servidor e de Cliente, permitindo que ele sirva a duas finalidades. Isso é particularmente importante para produtos como o Cisco Expressway que atuam como servidor e cliente em diferentes cenários de conexão.

A partir de junho de 2026, a Política do programa raiz do Chrome restringe os certificados de Autoridade de certificação raiz (CA) incluídos no Chrome Root Store, eliminando gradualmente as raízes multiuso para alinhar todas as hierarquias de infraestrutura de chave pública (PKI) para servir apenas casos de uso de autenticação de servidor TLS.
Note: Esta política se aplica somente a certificados emitidos por autoridades de certificação públicas. PKI particular e certificados autoassinados não são afetados por esta política.
Por Field Notice FN74362, todas as versões do Cisco Expressway são afetadas:
|
Produto |
Versões afetadas |
Impacto |
|
Núcleo e borda do Expressway |
X14 (Todas as versões) |
X14.0.0 a X14.3.7 - Todas as versões afetadas |
|
Núcleo e borda do Expressway |
X15 (Versões anteriores a X15.4) |
X15.0.0 a X15.3.2 - Todas as versões afetadas |
Os produtos Cisco Expressway (Expressway-C e Expressway-E) atuam como servidor e cliente em vários cenários de conexão, exigindo certificados com EKUs de autenticação de servidor e cliente.
Expressway E como servidor (EKU de autenticação de servidor necessário):
Expressway E como cliente (EKU de autenticação do cliente necessária):
O certificado assinado por CA público com EKU de autenticação de cliente atualmente usado para conexões mTLS no Cisco Expressway é o certificado de servidor Expressway. Este certificado é usado para as seguintes conexões mTLS:
Por Field Notice FN74362, antes de considerar as opções de solução e solução alternativa:
Os administradores podem escolher uma destas opções alternativas:
Algumas CAs de raiz pública (como DigiCert e IdenTrust) emitem certificados com EKU combinado de uma raiz alternativa, que não pode ser incluída no armazenamento confiável do navegador Chrome.
Exemplos de CAs raiz públicas e tipos de EKU (por FN74362):
|
Fornecedor de CA |
Tipo de EKU |
CA raiz |
Emitente/Sub CA |
|
IdenTrustName |
clientAuth + serverAuth |
CA raiz do setor público IdenTrust 1 |
CA 1 do IdenTrust Public Setor Server |
|
DigiCert |
clientAuth + serverAuth |
Raiz G2 do ID Assegurado do DigiCert |
ID garantida do DigiCert CA G2 |
Pré-requisitos para esta abordagem:
Referências de gerenciamento de certificados:

Os certificados emitidos por CAs de raiz pública antes de maio de 2026 que têm EKU de autenticação de servidor e de cliente continuam a ser honrados até o termo expirar.
As recomendações gerais são:
Por FN74362, se você usar os certificados Let's Encrypt:

Essa opção é aplicável a: Expressway C apenas; NÃO aplicável a Expressway E.
Caution: Essa opção não é viável para o Expressway-E, que requer certificados de CA públicos para serviços externos e confiança do navegador.
De acordo com o aviso de campo FN74362, a Cisco está implementando aprimoramentos de produtos em versões fixas para resolver esse problema de forma abrangente.
Plano de liberação fixo:
|
Produto |
Versão afetada |
Versão fixa |
Finalidade da correção |
Disponibilidade |
|
Cisco Expressway |
X14.x (Todas as versões)<br>X15.x (anterior a X15.4) |
X15.4 |
Solução intermitente: Permite o carregamento adicional de certificado assinado somente por EKU de ServerAuth no Expressway E e ajuste de verificação de certificado para sinal SIP MRA entre Expressway E e Expressway C |
Fevereiro de 2026 |
|
Cisco Expressway |
X14.x (Todas as versões)<br>X15.x (anterior a X15.5) |
X15,5 |
Solução abrangente: Fornece aprimoramentos de interface do usuário para segregar certificados de cliente e servidor e fornece opções para administradores desabilitarem a verificação de EKU |
Maio de 2026 |
Note: O Cisco Expressway E e o Expressway C devem ser atualizados para a mesma versão.
Objetivo: solução intermitente para acomodar certificados somente com EKU ServerAuth e para habilitar registros MRA
Os principais aprimoramentos são:
Quem pode atualizar para X15.4:
Requisitos importantes para X15.4:
As limitações de X15.4 são:
Objetivo: Solução abrangente para atender aos requisitos globais do programa Google Chrome Root
Principais aprimoramentos do produto:
Note: Nesse caso, o peer remoto também tem que suportar um modelo semelhante de EKU de Ignore Client Authentication

INICIAR: Você usa certificados CA públicos no Expressway?
│
├─: PKI particular ou autoassinado
│ └─ Nenhuma ação necessária - Não afetado pela política
│
└─ SIM: Certificados de autoridade de certificação pública em uso
│
├─ Eles são usados para conexões mTLS? (Verifique os casos de uso na seção Casos de uso afetados específicos)
│ │
│ N.├─: Somente autenticação de servidor
│ │ └─ Impacto mínimo - Monitora alterações futuras
│ │
│ └─ SIM: conexões mTLS com EKU de Autenticação de Cliente
│ │
│ └─ Escolha SUA abordagem:
│ │
│ ├─ Opção A: Alternar para CA raiz alternativa
│ │ ├─ Contate o provedor de CA para EKU combinado da raiz alternativa
│ │ ├─ Garantir que todos os pares confiem na nova raiz
│ │ └─ Sem necessidade imediata de atualização de software
│ │
│ ├─ Opção B: Renove os certificados antes dos prazos
│ │ ├─ Se Vamos Criptografar: Renove antes de 11 de fevereiro de 2026
│ │ │ └─ Desativar o programador ACME após a renovação
│ │ ├─ Para validade máxima: Renove antes de 15 de março de 2026
│ │ └─ Compra tempo até a expiração do certificado
│ │
│ ├─ Opção C: Migrar para PKI privada (apenas Expressway-C)
│ │ ├─ Configurar a infraestrutura de CA privada
│ │ ├─ Emitir certificados EKU combinados
│ │ ├─ Distribuir raiz para todos os pares
│ │ └─ Controle de longo prazo, NÃO para Expressway-E
│ │
│ └─ Opção D : Planejar Atualização do Software
│ ├─ Necessidade urgente? Atualização → para X15.4 (fevereiro de 2026)
│ └─ Solução abrangente → atualização para X15.5 (maio de 2026)
│ └─ Em seguida, obtenha certificados de servidor/cliente separados

P: Preciso me preocupar com isso se eu usar PKI privado?
R: Não. Esta política afeta somente certificados emitidos por CAs de raiz pública. A PKI privada e os certificados autoassinados não são afetados.
P: E se eu não usar conexões mTLS?
R: Se você usar apenas TLS padrão (autenticação de servidor), não será afetado por esta política. Seus certificados somente de servidor continuarão funcionando. No entanto, verifique seus casos de uso na lista da seção Casos de uso afetados específicos, pois alguns dos casos de uso padrão usam mTLS.
P: Minhas conexões da Web HTTPS padrão com o Expressway pararão de funcionar?
R: Não. As conexões TLS padrão não são afetadas. O acesso do navegador da Web ao Expressway continua a funcionar normalmente mesmo com certificados EKU somente de servidor.
P: Posso continuar usando meus certificados existentes?
R: Sim, os certificados existentes com EKU combinado permanecem válidos até expirarem. O problema surge quando você precisa renovar. Eles funcionam para conexões TLS e mTLS até expirarem.
P: Como sei se estou usando mTLS ou TLS padrão?
R: Reveja a seção Casos de Uso Afetados Específicos.
P. O que posso fazer agora?
R: A Cisco recomenda enfaticamente estas ações imediatas:
Identificar certificados TLS públicos usados para mTLS
Renove antes de 15 de março de 2026 para maximizar a validade
Desabilitar renovações automatizadas que podem substituir certificados inesperadamente
Algumas AC oferecem perfis de certificado temporários ou alternativos
P: O CUCM SU3(a) é compatível com X15.4 e X15.5
R: Yes
P: Há uma vulnerabilidade de segurança com a desabilitação da verificação de EKU do cliente no Cisco Expressway E (com a versão X15.5)
R: O certificado ainda verifica o CN/SAN para verificar se a fonte de conexão é válida, apenas ignora a validação de EKU (certificado para função de cliente), que foi incluída por padrão até que o Google manifeste preocupação com a segurança, portanto, não deve ter problema de segurança comparado a antes.
P: Eu uso Let's Encrypt with ACME no Expressway. O que eu posso fazer?
R:
P: Posso modificar o perfil ACME para continuar a obter certificados EKU combinados?
R: Não. Atualmente, o Expressway usa um perfil ACME "clássico" codificado que não pode ser modificado pelos usuários. Entre em contato com o TAC da Cisco para obter suporte ao perfil do certificado ACME.
P: Preciso atualizar o Expressway-E e o Expressway-C?
R: Sim, com certeza. Ambos devem ser atualizados para a mesma versão (X15.4 ou X15.5) para uma operação adequada.
P: posso atualizar para X15.4 ou esperar por X15.5?
R:
P: A replicação do meu cluster é interrompida após a renovação do certificado. O que aconteceu?
R: Provavelmente seu novo certificado tem apenas o EKU de Autenticação de Servidor, mas:
Definir o modo de verificação TLS como "Permissivo" (menos seguro)
Obter certificados com EKU combinado da raiz de CA alternativa
Atualizar para X15.4 ou posterior, ignorando a verificação de EKU de Autenticação de Cliente para ClusterDB
P: Após atualizar para X15.4, posso usar o modo de imposição com certificados somente de servidor em meu cluster?
R: Sim. Começando em X15.4, o Expressway ignora a verificação de EKU de Autenticação de Cliente para conexões mTLS ClusterDB. Portanto, a Verificação TLS pode ser definida como "Impondo" mesmo se um ou mais nós de cluster tiverem somente a EKU de Autenticação do Servidor.
P: Por que não posso carregar meu certificado através da GUI da Web do Expressway?
R: Antes de X15.4, a GUI da Web impõe uma validação codificada que exige que os certificados tenham EKU de autenticação de cliente. Se o seu certificado tiver apenas EKU de Autenticação de Servidor, você terá duas opções:
P: Após a atualização para X15.4, ainda não consigo carregar certificados somente de servidor para Expressway-E
R: Após o upgrade, certifique-se de que este comando esteja habilitado
EnableServerEkuUpload de CVS de certificado TLS XCP xConfiguration: Ligado
P: Atualizei para X15.4. Agora posso carregar certificados somente de servidor no Expressway-E e no Expressway-C?
R: Não. O X15.4 remove apenas a restrição de carregamento do Expressway-E. O Expressway-C ainda requer certificados EKU combinados para carregamento via GUI da Web. Isso ocorre porque o Expressway-C frequentemente atua como um cliente TLS em zonas de passagem de UC e requer EKU de autenticação de cliente. Certifique-se de executar esse comando no Expressway-E. Esse comando não é executado no Expressway-C
EnableServerEkuUpload de CVS de certificado TLS XCP xConfiguration: Ligado
P: Não consigo registrar a Licença inteligente após a renovação do certificado. Por quê?
R: A falha do Smart Licensing após a renovação do certificado geralmente NÃO está relacionada ao EKU:
P: O MRA requer EKU de autenticação de cliente no Expressway-E?
R: Depende da versão do Expressway:
Durante a sinalização SIP MRA, o Expressway-E envia seu certificado assinado em uma mensagem de SERVIÇO SIP para o Expressway-C
O Expressway-C valida o certificado, exigindo EKUs de autenticação de cliente e de autenticação de servidor
Sem EKU combinado, o registro SIP de MRA falha
O Expressway-C não valida mais o EKU de autenticação do cliente na mensagem de SERVIÇO SIP
O Expressway-E só precisa de EKU de autenticação de servidor para MRA
A UC Traversal Zone opera unidirecionalmente (o Expressway-C valida apenas o certificado do servidor Expressway-E)
P: Por que minhas Zonas de Vizinhos estão falhando após o upload doEKU de Autenticação de Servidor em Expresswayx15.4
R: Se você definir o modo de verificação TLS como "on", será necessário ter um EKU de autenticação de cliente. Assim, você pode desabilitar a verificação TLS na configuração da Zona Vizinha
P: Quais certificados são necessários para que o MRA funcione corretamente?
R: Para uma implantação de MRA típica:
|
Componente |
Requisitos do certificado |
EKU Necessário |
Notas |
|
Expressway-E (antes de X15.4) |
serverAuth + clientAuth |
Ambos |
Para validação de SERVIÇO SIP por Exp-C |
|
Expressway-E (X15.4+) |
somente serverAuth |
Somente servidor |
Verificação de EKU do cliente ignorada |
|
Expressway-C |
clientAuth + serverAuth |
Ambos |
Sempre atua como cliente no UC Traversal |
|
Zona de passagem de UC |
Validação unidirecional |
Exp-E: serverAuth Exp-C: clientAuth |
Exp-C valida o certificado do servidor Exp-E |
P: Meu MRA estava funcionando bem, mas depois de renovar meu certificado Expressway-E com EKU somente de servidor, o registro SIP falha. O que está errado?
R: Se você estiver executando uma versão anterior a X15.4, a sinalização SIP MRA exigirá que o Expressway-E apresente EKUs de Autenticação de Servidor e de Cliente na mensagem de SERVIÇO SIP. Suas opções:
P: Como obtenho um certificado com EKU combinado de DigiCert ou IdenTrust?
R: Entre em contato com o provedor de CA e solicite um certificado de sua raiz alternativa que ainda emite o EKU combinado.
P: Minha autoridade de certificação diz que só podem fornecer certificados somente de servidor. O que eu posso fazer?
R: Você tem várias opções:
P: O que acontece em 15 de junho de 2026?
R: O Chrome para de confiar em certificados TLS públicos que contêm EKUs de autenticação de servidor e cliente. Os serviços que usam esses certificados podem falhar.
P: Por que preciso renovar antes de 15 de março de 2026?
R: Após 15 de março de 2026, a validade do certificado será reduzida de 398 dias para 200 dias. Renovar antes dessa data dá a você o tempo de vida máximo do certificado.
P: Qual é o prazo para ação?
R: Há vários prazos finais:

: Suporte para certificado separado de servidor e cliente para Expressway
O desligamento do EKU de Autenticação de Cliente em certificados CA públicos representa uma mudança significativa na política de segurança que afeta as implantações do Cisco Expressway usando conexões mTLS. Embora essa seja uma mudança em todo o setor, a classificação de impacto é CRÍTICA de acordo com o aviso de campo FN74362, e é necessária uma ação imediata para evitar interrupções no serviço.
| Revisão | Data de publicação | Comentários |
|---|---|---|
1.0 |
13-Feb-2026
|
Versão inicial |
Feedback