Por que a GoDaddy está removendo o ClientAuth EKU e fazendo a transição para a hierarquia raiz R1 para a emissão de DV TLS?

A partir de 15 de junho de 2026, os certificados SSL / TLS publicamente confiáveis emitidos para uso de servidor não poderão mais incluir o uso de chave estendida de “Autenticação de cliente” (EKU: clientAuth). Aqui estão os pontos-chave para entender:

• A alteração faz parte da atualização da política do programa Chrome: os novos certificados devem incluir apenas a EKU “Autenticação do servidor”.
• Novos certificados públicos emitidos após essa data, que incluem clientAuth, não serão considerados confiáveis pelo Chrome.
• Os certificados emitidos com clientAuth antes de 15 de junho de 2026 não são afetados por essa alteração e permanecerão válidos até que expirem ou sejam revogados.
• Certificados de CA privada (para uso interno) não são afetados por essa alteração - ela se aplica apenas a certificados de confiança pública.

Resumindo: se sua organização usa certificados TLS públicos para autenticação de cliente (via clientAuth EKU), você precisará agir antes de 15 de junho de 2026 . Para uso de TLS de site padrão (apenas autenticação de servidor), essa alteração não exige ação. No entanto, é um lembrete oportuno para revisar seu certificado de uso, separar funções adequadamente e garantir que você esteja alinhado com o modelo de confiança em evolução.

Como GoDaddy implementará essa mudança

Nossos intermediários de assinatura / emissão G2 atuais não têm nenhum EKU listado, o que faz com que essa hierarquia não esteja em conformidade com os requisitos do programa Chrome Root. Como resultado, a emissão dos intermediários G2 afetados deve ser interrompida até essa data.

Em vez de criar novos intermediários de emissão na cadeia G2 & mdash; que está planejado para expirar / terminar com o Google em abril de 2027 & mdash; estamos movendo a emissão de DV para nossa nova hierarquia R1 para atender às restrições da política daqui para frente.

Estamos alterando a cadeia de emissão de DV público para que novos certificados de folha de DV sejam emitidos a partir da hierarquia TLS CA - R1 da GoDaddy, usando os certificados de CA de emissão TLS da GoDaddy.godaddy.com. Isso significa que a cadeia do emissor apresentada pelos servidores (folha + intermediário) pode ser diferente do que alguns sistemas têm visto historicamente, e qualquer ferramenta interna que assume um nome intermediário legado específico ou ordem da cadeia deve ser atualizada para aceitar a nova cadeia R1.

Além disso, os certificados secundários emitidos a partir dessa hierarquia não conterão o ClientAuth EKU. Qualquer fluxo de trabalho que dependesse de certificados folha DV sendo utilizável para autenticação de cliente TLS deve migrar para um perfil de certificado / caminho PKI apropriado. Durante a implementação, os certificados permanecem operacionais nos navegadores porque os clientes validam usando o caminho de confiança com assinatura cruzada R1 → G2 publicado em nosso repositório (certs.godaddy.com).

Como os certificados permanecem operacionais do navegador durante a transição R1 (sinal cruzado R1 → G2)

Conforme migramos a emissão pública de DV TLS para a hierarquia R1, a raiz R1 ainda está em processo de ser amplamente confiável / distribuída em armazenamentos confiáveis de navegador e sistema operacional. Para garantir que os certificados R1 recém-emitidos funcionem imediatamente nos navegadores, contamos com um caminho de confiança assinado cruzado de volta à raiz G2 já confiável.

Em termos práticos, o certificado secundário é emitido sob a CA de emissão de R1 DV, mas os clientes o validam criando uma cadeia para GoDaddy Class 2 Root - G2 usando o certificado cruzado R1 → G2 publicado. Os artefatos relevantes no repositório são a âncora de confiança G2 (gdroot-g2), o certificado cruzado (gd_tls_root-r1-cross-g2), o intermediário de emissão R1 DV (gd_tls_issuing_dv-r1v1) e a raiz de hierarquia nativa (gd_tls_root-r1) ) certs.godaddy.com. Essa abordagem de sinal cruzado permite que os navegadores validem a cadeia hoje (ancorando em G2), enquanto a confiança R1 se propaga com o tempo.

Por que essa alteração está sendo feita?

Há vários motivos para abandonar os certificados que oferecem suporte a serverAuth e clientAuth (também conhecidos como certificados de finalidade mista):

• Separar a autenticação do servidor da autenticação do cliente ajuda a simplificar o modelo de certificado confiável.
• Higiene de segurança aprimorada: Certificados com muitos propósitos aumentam o risco (ou seja, uso indevido de clientAuth de forma indesejada).
• O uso de hierarquias de PKI dedicadas para funções distintas ajuda a manter limites de confiança mais claros, alinhando-se com as melhores práticas de PKI (Infra-estrutura de chave pública).

Quais são os benefícios dessa mudança?

• Risco reduzido de certificados multiuso: Restringindo certificados públicos apenas para serverAuth, a superfície de ataque é reduzida e os limites de confiança são mais claros.
• Melhor conformidade & governança: as organizações terão uma separação mais clara entre a autenticação do servidor e a autenticação do cliente, o que pode oferecer suporte a uma melhor auditoria e gerenciamento do ciclo de vida do certificado.
• Clareza operacional aprimorada: Quando a funcionalidade clientAuth é separada em certificados ou infraestrutura apropriados, é mais fácil gerenciar funções, revogações, renovações e garantir que o certificado certo seja usado para a finalidade certa.
• Prontidão para o futuro: Essa mudança se alinha aos modelos de confiança de PKI / navegador em evolução e ajuda a posicionar as organizações para modelos de segurança e automação mais recentes.

Quem não é afetado?

A maioria dos sites que usam certificados apenas para autenticação de servidor (ou seja, TLS / HTTPS típico) não são afetados. Se você usa o certificado apenas para proteger seu site para os usuários, essa alteração não exige ação.

Quem é afetado?

Essa alteração afeta organizações que usam certificados de servidor confiáveis publicamente para autenticação de cliente (também conhecido como TLS / mTLS mútuo) ou autenticação de servidor para servidor que depende do clientAuth EKU. Por exemplo, alguns serviços financeiros, serviços SaaS ou APIs multilocatários podem ser afetados por essa alteração.

O que você precisa fazer

• Se você estiver hospedado fora da GoDaddy : Certifique-se de que o pacote completo fornecido pelos endpoints de download ou interface do cliente esteja sendo instalado quando atualizar seu próximo certificado.
• Se você estiver usando certificados em qualquer caso de uso que dependem do ClientAuth (mTLS) : Certifique-se de migrar esses fluxos de trabalho para usar um certificado autoassinado ou uma solução de CA privada.

As equipes também devem confirmar que nenhum recurso interno ou documentação pressupõe que os certificados secundários de DV incluam o ClientAuth EKU, já que os certificados secundários emitidos por R1 não o incluirão.

Isso significa que todos os certificados emitidos após 15 de junho de 2026 são inválidos?

Não. Os certificados emitidos antes de 15 de junho de 2026, que incluem clientAuth, permanecem válidos (até o vencimento) sob o modelo de confiança existente. A alteração afeta apenas os novos certificados públicos emitidos a partir dessa data.

Se eu usar meu certificado apenas para um HTTPS de site típico (autenticação de servidor), preciso fazer alguma coisa?

Se sua hospedagem for fora da GoDaddy, você ainda precisa garantir que o pacote seja usado corretamente.

O que exatamente é “autenticação de cliente” neste contexto?

A autenticação de cliente refere-se ao uso de um certificado por um cliente (usuário, dispositivo ou outro servidor) para autenticar no servidor. É comumente usado em mTLS (TLS mútuo) ou autenticação de API de servidor para servidor, em que o servidor precisa verificar o certificado apresentado pelo cliente conectado.

Ainda posso usar certificados clientAuth?

Sim, mas para confiança pública, você precisará usar um certificado emitido especificamente para autenticação de cliente (ou seja, clientAuth EKU) ou usar uma CA privada para seus sistemas internos. Os certificados de servidor público com clientAuth EKU não serão mais confiáveis no Chrome se emitidos após 15 de junho de 2026.

Outros navegadores farão essa alteração ou apenas o Chrome?

A política se origina do Programa Raiz do Chrome, mas as alterações no ecossistema público de PKI geralmente influenciam outros navegadores e armazenamentos de confiança. É aconselhável presumir uma aplicabilidade mais ampla ou, pelo menos, que a conformidade futura será importante entre as plataformas.

Isso se aplica a certificados de CA internos / privados?

Não & mdash; a alteração afeta apenas certificados SSL / TLS confiáveis publicamente (aqueles confiáveis pelos repositórios raiz públicos). A infraestrutura de CA privada usada para autenticação interna do cliente não é afetada diretamente.

Quando precisamos estar prontos para essa mudança?

O cronograma previsto é 27 de maio de 2026. Até essa data, as equipes responsáveis devem ter concluído a validação de prontidão (configuração de emissão, correção de pacote / download, orientação de instalação da cadeia de implantação, monitoramento e verificações de dependência de EKU) para que a implantação possa prosseguir sem interrupção do serviço.

Saiba mais

• Instalar e configurar meu Certificado SSL
• Se você ou seus clientes estiverem vendo erros de "raiz não confiável" ou de cadeia de certificados, consulte nossas etapas para solucionar o problema .