Resumo da gestão
Este post de blog aborda as próximas alterações relacionadas com a remoção do Client Authentication Extended Key Usage (EKU) de certificados SSL/TLS fidedignos publicados., uma mudança motivada por preocupações de segurança e pela necessidade de funções mais claras nas operações criptográficas.
A partir de setembro de 2025, as principais Autoridades de Certificação (ACs) começarão a eliminar gradualmente a EKU de Autenticação de Cliente da emissão de certificados públicos, com um prazo final para esta extensão em meados de 2026.
O principal objetivo destas alterações, de acordo com o fórum CA/B, é reduzir a segurançariscos associados aos certificados de dupla finalidade e aplicar orientações mais rigorosas para a sua utilização. As organizações que dependem de TLS mútuo ou autenticação de clientes terão de adotar certificados de cliente dedicados para garantir a conformidade e manter as operações seguras. Este blogue descreve as implicações destas mudanças, os benefícios de segurança que oferecem e os passos práticos para que as organizações se preparem para esta transição.
Introdução
A segurança e a conformidade são considerações primordiais para as organizações que utilizam certificados criptográficos para autenticação e comunicação. A remoção do Client Authentication Extended Key Usage (EKU) dos certificados SSL irá reformular a utilização destes certificados, especialmente em cenários de TLS mútuo (mTLS). Este blog fornece uma visão geral abrangente do Client Authentication EKU, as suas implicações e o cronograma para a sua implementação gradual. Ao compreender estas mudanças futuras, as organizações podem tomar as medidas necessárias para garantir que se mantêm em conformidade e seguras, bem como melhorar a clareza das suas práticas de gestão de certificados.
O que é o uso alargado de chave de autenticação de cliente (EKU)?
A autenticação de cliente EKU (Extended Key Usage) é uma extensão de certificado que designa um certificado digital para autenticar um cliente (como um utilizador ou dispositivo) num servidor, normalmente utilizado em cenários de TLS mútuo (mTLS).
É uma funcionalidade adicionada aos certificados digitais que especifica para que pode ser utilizada uma chave pública. Cria uma lista clara de utilizações aprovadas, garantindo que a chave é utilizada apenas para determinadas tarefas criptográficas. As utilizações permitidas são identificadas por números únicos denominados Object Identifiers (OIDs), que categorizam cada finalidade específica, como assinatura de código, autenticação de servidor, autenticação de cliente ou e-mail seguro.
Quando alguém verifica um certificado, consulta a EKU para encontrar o OID. Ao incluir a extensão EKU, uma Autoridade Certificadora (AC) limita a finalidade do certificado, ligando cada finalidade a um OID específico. Aqui estão alguns exemplos:
- Autenticação do servidor web TLS: O certificado pode ser utilizado para verificar um servidor, como por exemplo num site HTTPS. O OID para a Autenticação do Servidor é 1.3.6.1.5.5.7.3.1.
- Autenticação de cliente web TLS: O certificado pode ser utilizado por um cliente para se verificar num servidor, como no TLS mútuo. O OID para a Autenticação do Cliente é 1.3.6.1.5.5.7.3.2.
Normalmente, os browsers e os servidores requerem apenas a EKU serverAuth para configurar uma ligação HTTPS segura. No entanto, muitos certificados de servidor TLS incluem historicamente os EKUs serverAuth e clientAuth.
Utilização de EKU em PKI
- Os EKU restringem as funções permitidas de um certificado, como a autenticação de servidor, a autenticação de cliente, a assinatura de código ou a proteção de e-mail.
- Quando é necessária a autenticação do cliente (por exemplo, mTLS), a presença do EKU clientAuth sinaliza ao sistema que o certificado é fidedigno para este fim.
- Historicamente, alguns certificados TLS de servidor incluíam os EKUs serverAuth e clientAuth, mas esta prática está a ser descontinuada para reduzir os riscos de segurança e clarificar as funções criptográficas.
Mudanças na indústria
- A partir de 2025-2026, as principais CA e programas de raiz do browser (como o Google Chrome) exigirão a separação de EKU de autenticação de servidor e cliente, o que significa que os certificados TLS públicos devem ter apenas EKU serverAuth, e não clientAuth, para evitar o uso indevido e melhorar a segurança.
- As organizações que necessitam de autenticação de cliente necessitarão agora de certificados de cliente dedicados com o clientAuth EKU.
Impacto da remoção do EKU de autenticação do cliente nos certificados SSL
A remoção do EKU de autenticação do cliente dos certificados SSL significa que os futuros certificados de servidor público serão utilizados estritamente para autenticação do servidor e não para fins do lado do cliente, como o TLS mútuo (mTLS).
Impactos na utilização do certificado SSL
- Os certificados de servidor emitidos após meados de 2025 incluirão apenas o EKU serverAuth, evitando qualquer utilização ambígua ou insegura como credenciais de autenticação de cliente.
- Os certificados existentes (emitidos antes dos prazos) mantêm-se válidos até à data de vencimento; não serão revogados retroativamente.
- Os servidores web HTTPS padrão não são afetados, uma vez que os navegadores (como o Chrome e o Firefox) apenas verificam a autenticação do servidor e ignoram o clientAuth EKU para acesso ao site.
- Para ambientes que dependem de mTLS ou autenticação de cliente/dispositivo com certificados SSL públicos, será necessário um certificado de autenticação de cliente separado no futuro.
Benefícios de segurança e conformidade
- Reduz os riscos de utilização indevida e de utilização dupla não intencional, melhorando a separação entre a Internet pública e as infraestruturas de PKI internas.
- Alinha todas as Autoridades de Certificação (ACs) e navegadores sob diretrizes mais rigorosas que suportam certificados seguros e de propósito único.
Etapas para as Organizações
- Reveja os inventários de certificados para determinar quais os sistemas que dependem de certificados de utilização dupla/servidor para autenticação de clientes.
- Atualize os sistemas para utilizar certificados de cliente dedicados (com clientAuth EKU) para TLS mútuo, autenticação de dispositivo ou ligações de servidor para servidor.
- Modifique os processos/documentação de pedido de certificados para que as futuras renovações estejam em conformidade com as novas políticas e evitem interrupções de serviço.
Tabela de Efeitos
| Caso de uso |
Alteração após a remoção do EKU |
Ação necessária |
| Sites HTTPS |
Sem impacto; SSL padrão continua |
Nenhum |
| TLS mútuo (mTLS) |
Os certificados do servidor não podem autenticar os clientes |
Mudar para certificados de cliente dedicados |
| Sistemas Legados/Empresariais |
Certificados de dupla utilização rejeitados; possível incompatibilidade |
Atualizar sistemas, utilizar certificados de cliente dedicados |
A remoção do EKU de autenticação do cliente é uma medida de segurança para garantir que os certificados SSL são utilizados para os fins pretendidos, com um impacto mínimo para a maioria dos utilizadores, exceto aqueles que dependem de ambientes de autenticação mTLS ou mista.
Quando é que as AC deixarão de emitir certificados com autenticação de cliente EKU?
As Autoridades de Certificação (ACs) começarão a eliminar gradualmente os certificados SSL/TLS com a EKU de Autenticação de Cliente a partir de setembro de 2025, com datas de corte finais em meados de 2026, dependendo da AC.
Principais destaques da linha do tempo da CA
- 15 de setembro de 2025:A maioria das principais CA, incluindo a Sectigo e a Trustico, deixarão de incluir o EKU de autenticação do cliente por defeito nos novos certificados SSL.
- 1 de outubro de 2025:A DigiCert deixará de emitir certificados TLS públicos com o ClientAuth EKU por defeito. Os pedidos especiais poderão ser atendidos até 1 de maio de 2026, altura em que nenhum certificado público poderá incluir o ClientAuth EKU.
- 13 a 15 de maio de 2026:Prazos finais para todo o setor; todas as principais CA (incluindo Let’s Encrypt, Sectigo, DigiCert e Trustico) removerão permanentemente o Client Authentication EKU da nova emissão de certificados SSL/TLS públicos, incluindo renovações e reemissões.
- 15 de junho de 2026:O programa raiz do Google Chrome confiará somente em certificados SSL públicos com serverAuth EKU, rejeitando qualquer um com ClientAuth EKU a partir desta data.
Tabela Resumo
| Nome da CA |
Data de paragem padrão |
Prazo final rígido |
| Sectigo |
15 de setembro de 2025 |
15 de maio de 2026 |
| DigiCert |
1 de outubro de 2025 |
1 de maio de 2026 |
| Vamos encriptar |
Início de 2026 |
13 de maio de 2026 |
| Trustico |
15 de setembro de 2025 |
15 de maio de 2026 |
Após estes prazos, nenhum certificado SSL/TLS público, novo ou renovado, das principais CA conterá o EKU de autenticação do cliente, marcando a transição em todo o setor.
Quais são os benefícios de segurança ao remover o ClientAuth EKU?
De acordo com o fórum CA/B, a remoção do ClientAuth EKU de certificados SSL publicamente fiáveis traz vários benefícios importantes de segurança ao reforçar a especificidade da finalidade do certificado e reduzir os riscos de utilização indevida ou configuração incorreta.
Separação de Funções de Confiança
- Os certificados de servidor público serão utilizados estritamente para autenticação de servidores, e não para autenticação de clientes ou dispositivos.
- Isto minimiza a hipótese de os certificados serem reutilizados para além da sua função pretendida, aderindo ao princípio do menor privilégio.
Risco reduzido de configuração incorreta
- Alguns sistemas aceitavam anteriormente qualquer certificado com um ClientAuth EKU para autenticação de clientes, levando a um possível acesso não autorizado se um certificado de servidor público fosse confiado por engano.
- Restringir os EKUs aos seus usos pretendidos torna a arquitetura PKI mais clara e robusta para manutenção e auditorias.
Melhoria na higiene e conformidade da PKI
- A aplicação de hierarquias de certificados separadas para as funções de servidor e cliente alinha as Autoridades de Certificação (CAs) com os requisitos do browser e as normas modernas de PKI.
- Reduz a complexidade e a superfície de ataque dos certificados multiusos, facilitando a gestão e a proteção de implementações PKI públicas e privadas.
Prevenção do Abuso de Certificados Multiuso
- Os certificados de utilização mista (com os EKUs serverAuth e clientAuth) podem ser utilizados indevidamente se utilizados em esquemas de autenticação não intencionais, facilitando potencialmente a movimentação lateral ou a escalada de privilégios.
- Ao exigir certificados separados para cada finalidade, as organizações podem monitorizar, auditar e controlar melhor os cenários de acesso confidenciais.
Tabela Resumo
| Benefício de Segurança |
Descrição |
| Separação de funções (privilégio mínimo) |
Impede que os certificados sejam utilizados fora do âmbito |
| Reduz o risco de configuração incorreta |
Elimina a sobreposição acidental de EKU cliente/servidor |
| Melhora a arquitetura PKI |
Permite uma separação clara de PKI e aplicação de políticas |
| Reduz a superfície de ataque |
Não permite o acesso não intencional através de certificados multifuncionais |
Em resumo, a remoção do ClientAuth EKU dos certificados SSL do servidor reforça a segurança ao clarificar a utilização do certificado, impor a conformidade e reduzir o risco de que os certificados públicos sejam utilizados indevidamente para cenários de autenticação de clientes confidenciais.
Como preparar os seus sistemas para o calendário de descontinuação do EKU?
Para preparar os sistemas para o calendário de descontinuação do Client Authentication EKU, as organizações devem tomar medidas proativas para garantir operações seguras contínuas e conformidade até aos prazos de 2025-2026.
Etapas de preparação
- Inventário de certificados atuais e utilização
- Audite todos os certificados SSL/TLS existentes para identificar quais têm o Client Authentication EKU incluído.
- Determinar quais as aplicaçõesconfiar nestes certificados para autenticação de clientes (por exemplo, TLS mútuo, autenticação de dispositivos).
- Determine se e como estas aplicações que necessitam de um certificado público fidedigno ServerAuth e ClientAuth suportam realmente a configuração de certificados (e chaves) ClientAuth e ServerAuth separados. Caso contrário, contacte o fornecedor da aplicação quando esse recurso for disponibilizado.
- Planeie a segmentação de certificados
- Separe as funções de autenticação de cliente e de servidor utilizando certificados dedicados para cada finalidade.
- Obtenha certificados de cliente com o ClientAuth EKU estritamente para autenticação de cliente e certificados de servidor apenas com o ServerAuth EKU.
- Atualizar sistemas e aplicações
- Modifique o software cliente e servidor para suportar certificados distintos para TLS mútuo e outros métodos de autenticação do cliente.
- Garanta que as aplicações validam os valores EKU corretamente para evitar aceitar certificados inadequados.
- Ajustar os processos de gestão de certificados
- Atualize as políticas internas e a documentação para refletir as novas restrições à utilização do EKU.
- Coordenar com as CA para emissão de certificados sem ClientAuth EKU nos certificados de servidor após prazos.
5.º Teste e Valide
- Realize testes com alterações de certificados planeadas em ambientes de preparação ou desenvolvimento antes do lançamento da produção.
- Verifique se todos os fluxos de autenticação, incluindo o TLS mútuo, funcionam corretamente com novas definições de certificados.
- Comunique as alterações
- Informe as partes interessadas, incluindo TI, equipas de segurança e proprietários de aplicações sobre o impacto da descontinuação do EKU.
- Fornecer formação ou orientação sobre o manuseamento de novos certificados e práticas de PKI.
Tabela Resumo
| Ação |
Descrição |
| Inventário de certificados |
Identificar certificados com ClientAuth EKU |
| Utilize certificados dedicados |
Funções de cliente e servidor separadas com EKUs relevantes |
| Atualizações do sistema/aplicação |
Suporte e aplicação da utilização de certificados específicos da EKU |
| Ajuste de política/processo |
Refletir a depreciação da EKU nas políticas de emissão/renovação |
| Teste e validação |
Confirme a funcionalidade com novas definições de certificado |
| Comunicação com as partes interessadas |
Educar as equipas sobre as mudanças e conformidade do EKU |
Ao seguir este roteiro, as organizações podem minimizar as interrupções operacionais e manter uma forte postura de segurança PKI durante a transição de descontinuação do EKU de autenticação de clientes.
Informações específicas para clientes KeyTalk
A solução de gestão de certificados e chaves da KeyTalk permite a renovação automatizada de certificados (e chaves privadas) e fornece os meios para retransmitir, instalar e configurar automaticamente esses certificados no seu ponto final de destino para uma aplicação de destino.
Os clientes da KeyTalk que necessitem de certificados ClientAuth publicamente fiáveis são aconselhados a:
- Crie um novo modelo de certificado dedicado para o pedido de certificados ClientAuth publicamente fidedignos. A forma mais fácil é copiar o modelo de certificado multiusos existente e alterar o produto para o certificado ClientAuth da AC pública relevante. Não se esqueça de ligar o novo modelo de certificado à Autoridade de Registo de Base de Dados Interna.
- Defina manualmente os FQDN para as aplicações que necessitam de certificados ClientAuth como KeyTalk SEATs ou faça com que sejam criados automaticamente mediante novos pedidos de certificado autenticados.
- Teste se a inscrição foi bem-sucedida e se o seu KeyTalk CKMS obteve o tipo de certificado correto.
- Active o ACME quando aplicável para o seu novo modelo de certificado ClientAuth e anote o URL exclusivo do servidor KeyTalk ACME
- Configure, quando aplicável, os seus agentes ACME existentes em execução nos endpoints que alojam as aplicações que necessitam do certificado ClientAuth adicional, para solicitar um certificado adicional proveniente do URL ACME recentemente ativado.
- Configure, quando aplicável, os seus agentes KeyTalk Enterprise existentes em execução nos endpoints que alojam as aplicações que necessitam do certificado ClientAuth adicional, para solicitar um certificado adicional proveniente do modelo de certificado recentemente ativado e, quando necessário, atualize os scripts Powershell ou Bash ligados para aplicar corretamente o certificado ClientAuth obtido à aplicação de destino.
- Teste se os certificados ClientAuth automatizados foram obtidos corretamente e aplicados corretamente às suas aplicações de destino.
Você tem perguntas sobre este artigo ou sobre como o KeyTalk CKMS ajuda a simplificar a gestão e automação de certificados digitais? Nossa equipe de suporte está disponível 24 horas por dia, 7 dias por semana, para ajudá-lo e orientá-lo na implementação de uma arquitetura PKI totalmente automatizada por e-mail ou através da nossa página de contato.
A equipe KeyTalk
