Sectigo 博客
还在用公有证书做身份认证？请停止该做法。2026 年前你必须完成哪些调整
受 Chrome 全新根证书计划规则约束，到 2027 年 2 月，公有证书颁发机构（CA）将停止支持 TLS 客户端认证。依赖公有 SSL/TLS 证书完成用户、设备或应用身份认证的机构，需要切换至私有 CA。这一变更将影响 VPN、mTLS、Wi-Fi 接入配置等场景。现代化私有 CA 方案搭配证书生命周期管理（CLM），可提供安全、可扩展的落地路径。
2027 年 2 月，公钥基础设施（PKI）领域将发生一项根本性变更：多数机构尚未关注到这一调整，但很多主体都会受到影响。根据 Chrome 根证书计划的更新要求以及各证书颁发机构（CA）近期发布的公告，公有 CA 将不再颁发支持 TLS 客户端认证的证书.
对于依赖这类证书完成用户、设备或应用身份认证的机构而言，此次变更设置了明确的硬性截止时间。除非机构完成向私有 CA 的迁移，否则现有的认证工作流——尤其是那些默认依赖免费或自动化公有 CA、未被重点关注的工作流——将开始出现故障。
这一调整并非针对边缘场景的政策更新，而是一次结构性重构，重新定义了企业基础设施中身份认证的实现方式，而且其落地时间远比多数人认知的更早。
政策变更的背景与核心要求
这一变更的依据是Chrome 根证书计划政策 1.6，该政策要求 Chrome 信任库中包含的所有证书层级必须在 2027 年 3 月前仅专用于 TLS 服务端认证。简而言之，公有 CA 将不再被允许同时颁发包含 id-kp-serverAuth 和 id-kp-clientAuth 两个扩展密钥用法（EKU）的证书。这些 EKU 用于定义证书的允许用途，对应本次场景下的服务端认证或客户端认证能力。
相关执行工作已经启动。
Sectigo 已宣布，自 2025 年 9 月 15 日起，新颁发的 SSL/TLS 证书将不再默认包含客户端认证 EKU；到 2027 年 2 月，Sectigo 将从所有新颁发的 SSL/TLS 证书中永久移除客户端认证 EKU，该截止日后不设置任何例外。
这一政策调整契合当前浏览器对延迟吊销零容忍的整体趋势。Chrome 不再继续容忍多用途公有证书的存在，而是明确了边界：公有 PKI 仅用于服务端认证。如果需要客户端认证能力，请使用私有 CA.
什么是TLS客户端认证，以及您可能需要使用它的原因
当客户端、用户、设备或应用尝试连接服务器时，TLS客户端认证可让系统验证上述主体的身份。它与大众更熟悉的、用于验证网站身份的TLS服务器认证（应用于HTTPS）并不相同。
常见使用场景包括：
- VPN访问 为员工笔记本电脑颁发证书，用于远程连接时的身份验证。
- Wi-Fi接入 对员工设备进行身份认证，无需共享静态密码即可保障网络安全。
- Salesforce登录 或其他依赖终端设备内置客户端证书的SSO工作流。
- API的双向TLS（mTLS）认证，尤其适用于零信任架构下的CI/CD流水线或微服务间通信场景。
- DevOps环境中的设备或工作负载身份认证，包括基于容器的服务场景。
核心问题在于：许多组织在上述工作流中无意识地使用了公共证书颁发机构（CA）提供的客户端认证服务，原因通常是这类证书获取便捷、成本低廉，或已与ACME等自动化工具集成。
Google Chrome已将移除客户端认证功能作为根证书保留在Chrome根证书商店中的前置条件。由于多数其他浏览器遵循相同的根证书计划，真正具备全局信任度的客户端认证证书将逐步停止供应。
到2025/2026年，主流受公众信任的证书颁发机构（CA）完成从其TLS证书产品线中移除客户端认证EKU的操作后，仍依赖TLS客户端认证证书识别客户端身份的组织将很难（且很快将无法）找到替代证书。目前所有大型公共证书颁发机构（CA）均已公布相关淘汰时间表。
现代私有证书颁发机构（CA）：部署已不再像过去那样复杂
客户端认证本质上是一项内部安全功能。它需要灵活性、细粒度控制，以及证书不会因外部策略变更被吊销的保障。公共证书颁发机构（CA）从设计之初就并非服务于该场景。
直到近期，许多组织仍在使用公共CA提供的相关服务，且往往未意识到其中的影响。公共证书易获取、适配自动化流程，无需部署内部公钥基础设施（PKI）。但这类证书存在以下局限性：
- 固定的证书配置文件 证书模板固定，无法根据内部使用场景调整。
- 公共审计与合规强制要求 需遵守CA/浏览器论坛的公共审计与合规要求。
- 无法控制签发窗口 无法自主控制证书签发窗口、吊销规则或生命周期策略。
- 面临浏览器和平台策略变更的风险 易受浏览器与平台策略变更影响，比如当前正在发生的这类策略调整。
相比之下，私有证书颁发机构（CA）可让组织完全掌控证书的签发、模板设计、吊销、续期与自动化流程。更重要的是，这类CA不受外部根证书计划约束。如今，现代私有CA解决方案的部署难度远低于以往。
过去，私有CA一直存在成本高、难管理、部署慢的问题。组织必须从零搭建公钥基础设施（PKI），且往往依赖过时的工具和手动流程。
如今情况已发生改变。
现代私有证书颁发机构（CA），尤其是Sectigo这类云原生私有CA，可在数分钟内完成部署，支持自动扩缩容，且兼容ACME、EST、SCEP等协议，可实现顺畅的证书注册流程。这类CA可提供：
- 可定制的证书配置文件 适用于各类内部使用场景。
- 按使用场景划分的私有CA，满足权限分离的需求。
- 完整的API支持 可集成至DevOps、MDM及各类安全平台。
- 生命周期自动化与策略执行能力 可通过证书生命周期管理（CLM）平台实现。
这一演进影响深远，甚至直接推动了Chrome相关策略的调整。正如Sectigo高级研究员Jason Soroko所说：
“谷歌之所以有底气推进这项调整，是因为他们知道如今我们终于拥有了轻量、开箱即用的私有CA可选方案。要是放在15年前，他们根本不可能做出这个决策。”
换言之，私有CA基础设施终于发展到足以解决其设计初衷所要应对的问题的程度。
CLM如何补全整个方案
切换至私有CA并不只是替换证书这么简单，核心是要掌握证书的全流程管理方式。
随着SSL/TLS证书有效期缩短至47天成为既定规则，依靠电子表格跟踪证书状态、寄希望于续期脚本持续运行的模式已经不再可行。可见性、自动化与策略执行能力必须从初始阶段就内置到体系中。
这正是证书生命周期管理（CLM）的价值所在。成熟的CLM平台可协助你完成以下工作：
- 发现每一张证书 覆盖环境内所有公网及私有证书。
- 对证书进行分类与打标 按使用场景、所属系统、过期时间分类标记证书。
- 自动化完成证书签发、续期与吊销 实现证书签发、续期、吊销的规模化自动化处理。
- 执行策略管控 针对密钥长度、EKU、配置模板等维度执行强制策略。
- 避免业务中断 避免因证书过期或配置错误导致的业务中断。
- 通过单一管理面板查看所有证书，通过统一视图查看所有私有及公网证书。
无论你使用的CA能力多强，如果缺少CLM，在数字化环境持续快速迭代的背景下，你将很难保持管理的敏捷性。
“所有路径最终都指向CLM”，Jason表示，“每一张证书从一开始就应该被纳入管理体系。”
后续操作建议
1. 梳理内部公钥基础设施（PKI）现状
首先排查组织内所有使用TLS客户端身份验证的场景：
- 哪些设备、应用或服务正在使用证书进行身份验证？
- 这些证书由哪些证书颁发机构（CA）签发？
- 这些证书中是否有通过公共ACME工作流签发的（例如Let’s Encrypt）？
如果您无法确定，Sectigo Certificate Manager 可协助您发现并盘点云环境、本地环境及混合环境中的内部证书。
2. 评估风险与时间规划
如前文所述，所有公共CA需在2027年2月前完全终止对TLS客户端身份验证的支持。上述来源签发的所有支持客户端身份验证的证书，都需要替换为私有CA签发的证书。
3. 部署现代化私有CA
Sectigo的云原生私有CA解决方案 支持为以下场景签发和管理证书：
- VPN与Wi-Fi身份验证
- 设备与工作负载身份
- mTLS与API身份验证
- 开发环境与CI/CD流水线
该方案专为快速部署设计，可跨环境弹性扩展。它支持ACME、EST、SCEP协议，且提供与Microsoft ADCS及云身份平台的开箱即用集成，您可顺畅上线私有PKI，无需额外调整基础设施。
4. 通过证书生命周期管理（CLM）实现自动化
私有CA正式运行后，下一步需确保 完整的证书可见性与自动化能力。Sectigo Certificate Manager可为您提供：
- 所有证书（公共及私有证书）的完整资产清单
- 基于角色的签发策略
- 自动续期与轮换
- 过期告警与审计日志
私有PKI已成为必备能力
公共CA逐步终止TLS客户端身份验证支持并非单纯的政策更新，而是身份验证处理逻辑的结构性调整，这将移除许多组织多年来在不知情情况下依赖的一种不当实现方式。
好消息是：私有证书颁发机构（CA）已不再像过去那样是实施障碍. 随着证书管理工具的不断成熟，现在正是重新夺回控制权的最佳时机。
如果您仍在传阅Wi-Fi密码，或使用公有证书颁发机构（CA）颁发的客户端证书为笔记本电脑做身份认证，现在就该采取行动了。您所需的基础设施已经就绪，最后期限也已明确。
Sectigo可提供贵组织所需的解决方案，帮助您在保持合规性的同时兼顾敏捷性。我们提供开箱即用、业界领先的CA无关型私有证书颁发机构（CA），以及安全、简便、可扩展的平台，可帮助您将公有和私有证书统一管理。
