每个人都可以，
拥有SSL证书

华为云CCM那条通知很简短，但信息密度不低：2026年8月起，GlobalSign的OV、EV类型SSL证书会改用Root R46/E46根证书和新的中级CA证书签发，原来的R3根证书体系逐步淘汰。很多运维第一反应是要换证书，实际上真正会出问题的不是证书本身，而是服务端拼接出来的证书链。

证书链的验证逻辑有点像银行授权。根证书像央行总行，中间CA像省分行，网站证书像商户手里的POS机授权。浏览器和操作系统内置了央行总行，验签时会从商户授权一路向上追到省分行、再追到总行。如果商户只出示自己的授权书，却拿不出省分行那级证明，交易在刷卡机面前就会失败。HTTPS证书也一样，服务端必须把网站证书和中间CA证书一起配置完整。

这次GlobalSign把R3根迁移到R46/E46，不是说旧证书立即失效，而是新签发的OV、EV证书会挂在新的中级CA下面。

已经固定写死旧中间证书的配置，或者只上传了叶子证书的CDN、负载均衡、WAF，就会出现链路不完整。

用 OpenSSL 可以直接看到这类故障：

openssl s_client -connect example.com:443 -showcerts

常见输出不是证书过期，而是：

Verification error: unable to verify the first certificate

这个报错在业务侧往往表现为小程序、App、API客户端请求失败，PC浏览器却可能因为 AIA 扩展自动补链而正常。不同客户端补链策略不一致，恰恰是这类问题容易误判的原因。

GlobalSign 目前常见的 R3 链大致是 GlobalSign Root CA - R3，向下由 GlobalSign Extended Validation CA - SHA256 - G3 给站点证书签名。换成 R46/E46 后，中间节点会换成新的 CA 名称和公钥。

拿着新叶子证书，却还用旧中间节点拼链，验签自然失败。

更难缠的是，证书链不完整在监控里不一定第一时间暴露。普通拨测只要 TCP 和 TLS 握手通过，HTTP 状态码 200，就很少再逐级验链。

部分客户端会报证书告警，部分直接断开，PC 浏览器又可能自动补链，于是同一个域名在不同终端表现完全不同。

真正麻烦的是证书分布太散。生产环境、预发环境、CDN 回源、API 网关、小程序后台，证书可能都不是同一份。GlobalSign 根迁移后，每处都要更新叶子证书和中间证书。手动维护时，开发环境常被忽略，结果本地测通、线上握手失败，排查时还要逐个节点抓包。

ACME协议这两年的普及，让证书申请、验证、部署、续期从手工拼接变成了自动流程。

Let's Encrypt、Google Trust Services、ZeroSSL 这些 CA 都支持ACME，根证书或中级CA变更时，续期会重新下发完整链，不用再手工核对中间证书。

lcjmSSL 这类平台把几家支持ACME的可信CA封装成统一API，多域名、泛域名、IP证书都能自动申请和部署。

根迁移这种场景下，平台侧更新对应CA的中间链，业务侧只需要按续期流程拉取新链，等于把证书链完整性纳入了自动管理。

GlobalSign 根证书切换不是孤立事件，CA厂商每隔几年都会做根轮换。真正值得复盘的不是某个品牌换根，而是证书链配置是否还停留在手工时代。

自动化程度越高，这类变更对业务的冲击越小。