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 do 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 a compreender:

• A alteração faz parte da atualização da política do Programa de raiz do Chrome: os novos certificados devem incluir apenas a EKU “Autenticação do servidor”.
• Os novos certificados públicos emitidos após essa data, que incluem clientAuth, não serão confiados pelo Chrome.
• Os certificados emitidos com clientAuth antes de 15 de junho de 2026 não são afetados por esta alteração e permanecem válidos até expirarem ou serem revogados.
• Os certificados de CA privada (para uso interno) não são afetados por esta alteração & mdash; aplica-se apenas a certificados publicamente confiáveis.

Resumindo: se a sua organização usa certificados TLS públicos para autenticação de cliente (via clientAuth EKU), terá de agir antes de 15 de junho de 2026 . Para utilização de TLS de site web padrão (apenas autenticação de servidor), esta alteração não requer ação. No entanto, é um lembrete oportuno para rever o seu certificado de utilização, separar as funções de forma adequada e garantir que está alinhado com o modelo de confiança em evolução.

Como GoDaddy implementará esta alteração

Os nossos intermediários de assinatura / emissão G2 atuais não têm qualquer EKU listada, o que faz com que essa hierarquia não esteja em conformidade com o requisito do Programa Raiz do Chrome. Como resultado, a emissão dos intermediários G2 afetados deve ser interrompida nessa data.

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

Estamos a alterar a cadeia de emissão de DV público para que sejam emitidos novos certificados de folha de DV a partir da hierarquia TLS CA - R1 de GoDaddy, utilizando os certificados de CA de emissão de TLS 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 de intermediário legado específico ou ordem de cadeia deve ser atualizada para aceitar a nova cadeia R1.

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

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

À medida que migramos a emissão de DV TLS pública para a hierarquia R1, a raiz R1 ainda está em processo de ser amplamente confiada / distribuída nos armazenamentos fiduciários do navegador e do SO. Para garantir que os certificados R1 recém-emitidos funcionem imediatamente nos navegadores, contamos com um caminho de confiança com assinatura cruzada de volta à raiz G2 já confiável.

Em termos práticos, o certificado secundário é emitido ao abrigo da CA de emissão de R1 DV, mas os clientes o validam criando uma cadeia para a Raiz de Classe 2 de GoDaddy - G2 utilizando 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. Esta abordagem de sinal cruzado permite que os navegadores validem a cadeia hoje (ancorando em G2), enquanto a confiança de R1 se propaga ao longo do tempo.

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

Existem vários motivos para abandonar os certificados que suportam 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 de confiança.
• Higiene da segurança aprimorada: certificados com muitos propósitos aumentam o risco (ou seja, uso indevido de clientAuth de formas não intencionais).
• 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) mais amplas.

Quais são os benefícios desta alteração?

• Risco reduzido de certificados multiusos: ao restringir os certificados públicos apenas ao 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 suportar uma melhor auditoria e gestão do ciclo de vida do certificado.
• Clareza operacional melhorada: quando a funcionalidade clientAuth é separada em certificados ou infraestruturas adequadas, é mais fácil gerir funções, revogações e renovações e garantir que o certificado certo é utilizado para o fim certo.
• Preparação para o futuro: esta alteração está alinhada com os modelos de confiança de navegador / PKI em evolução e ajuda a posicionar as organizações relativamente a modelos de segurança e automatização mais recentes.

Quem não é afetado?

A maioria dos sites web que usam certificados apenas para autenticação de servidor (ou seja, TLS / HTTPS típico) não são afetados. Se apenas utiliza o certificado para proteger o seu site na web para os utilizadores, esta alteração não requer ação.

Quem é afetado?

Esta alteração afeta as organizações que usam certificados de servidor publicamente confiáveis 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 de SaaS ou APIs de vários inquilinos podem ser afetados por esta alteração.

O que você precisa fazer

• Se estiver alojado fora da GoDaddy : Certifique-se de que o pacote completo fornecido pelos terminais de transferência ou interface do cliente está a ser instalado quando atualizar o seu próximo certificado.
• Se estiver a utilizar certificados em qualquer caso de utilização que dependem do ClientAuth (mTLS) : Certifique-se de que migra esses fluxos de trabalho para utilizar um certificado autoassinado ou uma solução de CA privada.

As equipas também devem confirmar que nenhuma funcionalidade ou documentação interna pressupõe que os certificados de folha de DV incluem a EKU de ClientAuth, uma vez que os certificados de folha emitidos por R1 não a incluem.

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é à expiração) 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 HTTPS (autenticação de servidor) de site da Web típico, preciso fazer algo?

Se o seu alojamento for fora da GoDaddy, ainda precisa de se certificar de que o pacote é utilizado corretamente.

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

A autenticação de cliente refere-se à utilização de um certificado por um cliente (utilizador, dispositivo ou outro servidor) para se autenticar no servidor. É normalmente utilizado em mTLS (TLS mútuo) ou autenticação de API de servidor para servidor, em que o servidor necessita de verificar o certificado apresentado pelo cliente de ligação.

Posso continuar a utilizar certificados clientAuth?

Sim & mdash; mas para a confiança pública, precisará de usar um certificado emitido especificamente para autenticação de cliente (ou seja, clientAuth EKU dedicado) ou usar uma CA privada para os 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 irão aplicar esta alteração ou apenas o Chrome?

A política tem origem no Programa de raiz do Chrome, mas as alterações no ecossistema de PKI pública muitas vezes influenciam outros navegadores e lojas de confiança. É sensato presumir uma aplicabilidade mais ampla ou, pelo menos, que a conformidade futura será importante em todas as plataformas.

Isto se aplica a certificados de CA internos / privados?

Não & mdash; a alteração afeta apenas certificados SSL / TLS publicamente confiáveis (aqueles em que os armazenamentos de raiz públicos confiam). A infraestrutura de CA privada usada para autenticação de cliente interna 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 continuar sem interrupção do serviço.

Mais informações

• Configurar e instalar o 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 .