2026 年 2 月 17 日，Google 公共证书认证机构（Google Public CA）发生服务中断，导致依赖该 CA 进行 TLS 证书发行的新请求全面受阻。此次事件并非已有证书的验证失效，而是发行流程的全面挂起 —— 这意味着企业面临的核心风险是即将过期或新部署的服务无法及时获取证书，而非现有加密通道的突然断裂。理解这一区别是制定有效监控和回退策略的前提。
事件本质：发行中断而非验证失败
从 Google PKI 状态页面（status.pki.goog）披露的信息来看，此次中断的影响范围集中于证书发行环节。Google Trust Services（GTS）在太平洋时间 2026 年 2 月 17 日 11:18 左右发布 incident 通告，声明受影响的 CA 层级将暂停发行新证书。已签发的现有证书在有效期内仍可正常通过验证，TLS 握手不会因此次事件而失败。
这一细节直接影响监控策略的设计方向：传统的「证书到期监控」仍然必要，但更重要的是监控「发行管道的健康状态」。当主用 CA 无法发行证书时，企业需要在最短时间内切换至备用 CA，以确保业务连续性。根据行业实践，一次 CA 中断的平均恢复时间通常在 4 至 8 小时之间，这意味着任何依赖该 CA 进行自动续期的证书都可能在窗口期内失效。
多维度监控体系构建
有效的 CA 监控应从三个互补的视角展开：证书生命周期视角、发行管道视角和运行时行为视角。
在证书生命周期层面，企业应维护完整的证书资产清单，通过证书生命周期管理（CLM）平台记录每张证书的签发 CA、扩展用途（EKU）、主题备用名称（SAN）、所属环境和业务关键程度。特别需要标注那些由 GTS 签发且将在未来 30 天内到期的证书 —— 这些是 CA 中断期间的高风险资产。监控告警应按时间窗口分级配置：30 天、14 天和 7 天各设一道告警线，临近到期时提升告警级别。
在发行管道层面，需要针对 ACME 协议调用、API 请求和证书服务配额进行实时监控。关键指标包括：证书创建失败率突增、CA Service KMS 密钥异常、发行请求触发速率限制等。建议设置两类自动化告警 —— 一是「来自 CA X 的发行失败率在过去 Z 分钟内超过 Y%」，二是「过去 N 分钟内 CA X 没有任何成功发行记录」。后者是 CA 服务中断的最强信号，应直接触发回退流程。
在运行时行为层面，建议从多个地域部署合成探测节点，执行完整的 TLS 握手并验证证书链、OCSP 响应和证书主题匹配。探测应覆盖所有面向公众的业务域名，捕获过期证书、即将到期证书（7 天窗口）和 EKU 配置异常（如公网 CA 同时签发 serverAuth 和 clientAuth，Chrome 将于 2026 年 6 月起逐步淘汰此类证书）等情况。
备用 CA 架构设计原则
CA 回退机制不应是中断发生时的临时应对，而应在日常运维中作为「CA 敏捷性」能力预先建设。
首先，企业应预先选定并测试至少一个备用公共 CA。该备用 CA 应满足以下条件：已签订正式合同、验证方法与主用 CA 一致（均为 BR 合规的域验证流程）、自动化发行接口已完成对接。典型的备选方案包括 DigiCert、GlobalSign 或 Let's Encrypt（面向非关键业务）。备用 CA 的根证书和中间证书应提前注入到客户端信任存储中，避免切换时出现证书链验证失败。
其次，必须严格区分服务器认证和客户端认证的 CA 用途。Chrome 根程序策略 1.6 要求，到 2026 年 6 月，Chrome 信任存储中的公共 CA 必须专用 于 TLS 服务器认证，不得再签发同时包含 serverAuth 和 clientAuth 的证书。因此，公共 CA（如 GTS）应仅用于 HTTPS 服务器证书；而 mTLS 场景下的客户端认证必须依赖私有 CA 体系。这一架构分离确保了公共 CA 的任何中断或策略变动都不会影响内部 mTLS 服务的正常运行。
第三，发行工作流应实现 CA 无关的抽象设计。无论使用 ACME 客户端、cert-manager 还是自研脚本，都应将 CA 选择作为可配置参数而非硬编码值。推荐的做法是建立 CA 优先级映射：生产环境外网服务首选 GTS、备选 Backup Public CA；内部服务统一使用私有 CA。当主用 CA 触发中断告警时，只需修改配置中的优先级即可完成全局切换。
中断响应操作清单
当监控体系检测到 GTS 发行中断持续超过预设阈值（如 15 分钟）时，应按以下清单执行回退操作：
第一步是影响分类。通过证书清单筛选出所有 GTS 签发且在未来 14 天内到期的证书，以及所有业务关键域名（公共 Web、API 网关、认证端点）对应的证书。评估其中有多少依赖自动续期且将在中断窗口内失效。
第二步是切换发行。对可接受 CA 切换的业务，立即在备用 CA 上重新签发证书并部署上线。对存在证书 pinning 的客户端应用（如移动端应用或内部 Agent），需要分阶段推进信任更新 —— 先向客户端推送新 CA 根证书，再完成证书切换。
第三步是冻结非必要变更。中断期间应暂停所有可能触发重新签发的变更操作，如添加 SAN、密钥轮换等。优先使用 DNS 或负载均衡器层面的调整来应对业务需求变化。
第四步是记录与回滚。详细记录哪些端点从 GTS 切换至备用 CA，并明确标注切回条件 —— 建议在 GTS 事件关闭且稳定运行 48 小时后再执行回切，以避免因过早回切导致的二次中断。
面向 2026 年的长期防护
此次 GTS 中断发生的时间节点恰好与 Chrome 多项 PKI 政策调整重叠。2026 年 Chrome 将逐步淘汰公共 CA 签发的 clientAuth 证书，并收紧对根证书项目的管理。这些政策变化意味着企业需要将 CA 视作需要主动管理的动态依赖项，而非一次配置即可长期忽视的静态组件。
建议企业每季度审查一次证书资产组合，评估是否有证书因 CA 政策变动而面临失效风险。同时，将 CA 中断场景纳入业务连续性计划（BCP），至少每年进行一次 CA 切换演练，确保团队熟悉操作流程且工具链运行正常。
资料来源：Google PKI 状态页面（status.pki.goog）、Google Trust Services 证书策略文档、GCP Certificate Manager 最佳实践、Chrome 根程序政策 1.6。