浏览器正在逐步淘汰驱动这项技术 客户认证SSL.com 构建了一条保护双方安全的路径。TLS 部署正常 和 让您的网站在任何地方都值得信赖，无需您在两者之间做出选择。
多年来，一张数字证书可以身兼两职：既能向访客证明服务器的身份，又能向访客证明客户端的身份。这种双向握手是网络的核心。 相互 TLS (mTLS)它是安全 API、互联设备和零信任网络背后默默无闻的功臣。正是它让系统能够确认连接另一端的对象与它声称的身份完全一致。
现在情况发生了变化。Chrome 已经开始停止对……的支持。 客户认证 公共网络信任生态系统内部具备相应的能力，预计 Mozilla 也将效仿。浏览器的理由是合理的：用于保护公共网站的证书和用于验证客户端身份的证书正日益被视为两项不同的任务，理应由不同的机构管理。
这对于网络来说是一种良好的卫生习惯。但如果你的业务依赖于……TLS这引出了一个令人不安的问题： 为了让网站在现代浏览器中正常运行，是否必须放弃可信客户端身份验证？
对于 SSL.com 来说，答案是否定的。
双根两用，两份工作，绝不妥协
把根证书想象成最终的信任来源，是浏览器和操作系统共同认可的锚点。SSL.com 运营着不止一个根证书，而这正是整个故事的关键所在。
- 我们的 2016 年根 旨在 一般用途它们旨在支持多种用途，包括客户端身份验证。TLS 依靠。
- 我们的 2022 年根 旨在 专为 TLS — 完全致力于保护网站安全，这正是浏览器现在所青睐的方式。
当 Chrome 决定停用客户端身份验证时，SSL.com 主动做出了决定，而不是被动地等待通知：我们 要求 Chrome 从其应用商店中删除我们通用的 2016 年根目录。主动清除树根听起来似乎有悖常理，但这恰恰是保持环境清洁的关键。
从浏览器中移除通用根目录，可以让浏览器继续执行它不再想做的工作。
这就是它奏效的原因。我们的 2022 年 TLS 根 旨在 这些证书已添加到 Chrome 的信任存储区，因此任何链接到这些证书的网站证书如今都受到 Chrome 的完全信任。而这些 2022 年的根证书是 交叉签名 通过较早的 2016 年根证书——一种可信的引荐机制，即已有的根证书为较新的根证书提供担保。这种交叉签名使您的网站证书能够广泛且持久地兼容尚未自行添加 2022 年根证书的大量旧设备和系统。
与此同时，2016 年发布的通用 root 用户，由于已从浏览器应用商店下架，可以继续自由发布应用。 mTLS 同时包含客户端身份验证和服务器身份验证的证书这是双方握手所需的两种能力。它们无需获得浏览器的信任即可完成这项工作。浏览器在此次握手过程中已不再发挥作用。TLS 总之，重要的是…… 您的 系统信任颁发根证书的源，它们也确实会这样做。
这对你意味着什么
您的公共网站在 Chrome 和所有现代浏览器中都保持可信状态。 你的 mTLS 部署、API、物联网设备、内部服务网格、合作伙伴集成，确保客户端身份验证不间断。一个供应商，一种合作关系，满足双方需求。
为什么现在很重要
大多数证书提供商最终都会强制进行彻底的拆分，届时客户要么得四处寻找其他客户端身份验证证书来源，要么就得在时间紧迫的情况下重新设计部署方案。SSL.com 预见到了这一变化，并提前做好了应对措施，因此过渡工作将由我们完成，无需您操心。
- 无需重新架构。 您现有的 mTLS 现有模式将继续沿用以往颁发证书的方式。
- 浏览器未出现故障。 网站证书链指向 Chrome 已信任的根证书，并通过交叉签名扩展到较旧的环境。
- 一位值得信赖的合作伙伴。 服务器身份和客户端身份均来自具有悠久公开审计历史且根植于整个生态系统的 CA。
这就是与将根证书策略视为核心产品而非事后考虑的证书颁发机构合作的优势所在。浏览器格局将不断演变，能够预见这些变化的提供商的价值只会与日俱增。
维护好信任的双方。
联系 SSL.com 了解详情TLS 具有客户端身份验证和服务器身份验证的证书，以及 TLS 所有现代浏览器都信任的证书，来自一个面向未来的单一 CA。
