为什么GoDaddy删除ClientAuth EKU并过渡到R1根层次结构以发布DV TLS？

从2026年6月15日开始，颁发用于服务器使用的受公共信任的SSL / TLS证书将不再被允许包含“客户端身份验证”（EKU：clientAuth）扩展密钥用法。以下是需要理解的关键点：

• 更改是Chrome根目录程序政策更新的一部分：新证书必须仅包含“服务器身份验证” EKU。
• 在此日期后颁发的包含clientAuth的新公共证书将不受Chrome信任。
• 在2026年6月15日之前使用clientAuth颁发的证书不会受到此更改的影响，并将在其过期或被撤消之前一直有效。
• 专用CA证书（用于内部使用）不受此更改的影响—仅适用于公开信任的证书。

简而言之：如果您的组织使用公共TLS证书进行客户端身份验证（通过clientAuth EKU），则需要在2026年6月15日之前采取行动。对于标准网站TLS使用量（仅服务器身份验证），此更改无需操作。但是，这会及时提醒您，请查看您的使用证书，适当地分隔功能，并确保您与不断发展的信任模型保持一致。

如何GoDaddy实施此更改

我们当前的G2签名/发行中间没有列出任何EKU，这会使该层次不符合Chrome根目录程序要求。因此，从受影响的G2中间产品发行必须在该日期之前停止。

与其在G2链上创建新的发行中间产品-计划在2027年4月与Google一起过期/结束-我们是将DV发行移至我们的新R1层次结构，以满足未来的政策约束。

我们正在更改公共DV颁发链，因此使用GoDaddy TLS中间CA DV-R1v1颁发CA certs.godaddy.com，从GoDaddy TLS根CA – R1层次颁发新的DV分支证书。这意味着，由服务器显示的发布者链条（“叶子+中间产品”）可能与某些系统在历史上看到的情况有所不同，并且假定某个特定旧版中间产品名称或链顺序的任何内部工具都必须进行更新，才能接受新的R1链。

此外，从此层次结构颁发的分支证书将不包含ClientAuth EKU。任何依赖于DV叶子证书用于TLS客户端身份验证的工作流，都必须迁移到适当的证书基本资料/ PKI路径。在推出期间，证书将在浏览器中保持可操作状态，因为客户端将使用在我们的存储库（certs.godaddy.com）中发布的必需的R1→G2交叉签名的信任路径进行验证。

证书在R1过渡期间如何保持浏览器可操作性（R1→G2交叉签名）

当我们将公共DV TLS签发迁移到R1层次结构时，R1根目录仍处于在浏览器和OS信任库中广泛信任/分发的过程。为了确保新颁发的R1证书可以在浏览器中立即使用，我们依赖于返回到已信任的G2根目录的交叉签名信任路径。

实际上，分支证书是根据R1 DV颁发证书的CA颁发的，但是客户端通过使用发布的R1→G2交叉证书构建到GoDaddy 2级根– G2的链来验证证书。存储库中的相关构件包括G2信任锚（gdroot-g2），交叉证书（gd_tls_root-r1-cross-g2），R1 DV颁发中间件（gd_tls_issuing_dv-r1v1）和本机层次结构根（gd_tls_root-r1） ）certs.godaddy.com。这种交叉符号方法允许浏览器今天验证链（锚定在G2），而R1信任会随着时间传播。

为什么要进行此更改？

放弃支持serverAuth和clientAuth的证书（也称为混合证书）的原因如下：

• 将服务器身份验证与客户端身份验证分开有助于简化证书信任模型。
• 改进的安全卫生措施：目的过多的证书会增加风险（也就是说，以不必要的方式滥用clientAuth）。
• 将专属PKI层次结构用于不同的功能有助于维护更清晰的信任边界，并与更广泛的PKI（公钥基础设施）最佳实践保持一致。

此项更改有什么好处？

• 降低多用途证书带来的风险：通过将公共证书限制为仅限serverAuth，可减少攻击面，并简化信任边界。
• 更好的合规&和治理：组织将在服务器身份验证和客户端身份验证之间更清晰地分开，从而可以支持更好的审计和证书生命周期管理。
• 改进的操作透明度：将clientAuth功能拆分为适当的证书或基础设施后，可以更轻松地管理角色，吊销，续费，并确保将正确的证书用于正确的目的。
• 未来就绪：此更改与不断发展的PKI /浏览器信任模型保持一致，并有助于为组织定位新的安全模型和自动化。

谁不受影响？

大多数只将证书用于服务器身份验证（即典型的TLS / HTTPS）的网站不会受到影响。如果您只使用此证书为用户保护网站，则此更改无需操作。

谁受到影响？

此更改会影响使用公共可信服务器证书进行依赖客户端授权EKU的客户端身份验证（也称为相互TLS / mTLS）或服务器到服务器身份验证的组织。例如，某些金融服务，SaaS服务或多租户API可能会受到此更改的影响。

您需要做什么

• 如果您托管在GoDaddy之外：确保在更新下一个证书时正在安装下载终端或客户界面提供的完整捆绑包。
• 如果您在任何依赖于ClientAuth（mTLS）的用例中使用证书：请确保您将这些工作流程迁移为使用自签名证书或私有CA解决方案。

团队还应确认没有内部功能或文档假定DV叶子证书包含ClientAuth EKU，因为R1颁发的叶子证书将不包含ClientAuth EKU。

这是否意味着2026年6月15日之后颁发的所有证书都是无效的？

不会。在现有信任模型下，于2026年6月15日之前颁发的包含clientAuth的证书将保持有效（至过期）。更改仅影响在该日期或之后颁发的新公共证书。

如果我仅将证书用于典型的网站HTTPS（服务器身份验证），我是否需要执行任何操作？

如果主机位于GoDaddy外部，则仍需要确保正确使用捆绑包。

在这种情况下，“客户端身份验证”到底是什么？

客户端身份验证是指客户端（用户，设备或其他服务器）使用证书来向服务器身份验证。它常用于mTLS（相互TLS）或服务器到服务器API身份验证中，在此情况下，服务器需要验证连接客户端提供的证书。

我可以完全仍然使用clientAuth证书吗？

是的＆mdash;出于公众的信任，您将需要使用专门为客户端身份验证颁发的证书（即专属clientAuth EKU）或对内部系统使用隐私CA。如果在2026年6月15日后颁发证书，则带clientAuth EKU的公共服务器证书在Chrome中将不再受信任。

其他浏览器是否会强制执行此更改，或只是Chrome？

该政策源于Chrome根目录计划，但公共PKI生态系统中的更改通常会影响其他浏览器和信任库。明智的做法是假定适用范围更广，或者至少将来的合规性对各个平台都重要。

这是否适用于内部/专用CA证书？

否-更改仅影响公共信任的SSL / TLS证书（公共根存储信任的证书）。用于内部客户端身份验证的私有CA基础设施不会直接受到影响。

我们什么时候需要准备好进行此更改？

目标时间线是2026年5月27日。在该日期之前，负责的团队应该已经完成了准备就绪验证（发布配置，捆绑/下载正确性，部署链安装指导，监控和EKU依赖检查），以便可以继续进行推出，而不会中断服务。

更多信息

• 设置并安装我的 SSL 证书
• 如果您或您的客户遇到“不受信任的根”或证书链错误，请参阅我们的解决此问题的步骤。