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

GlobalSign 8 月 26 日推进 OV、EV 商业证书根架构迁移，新签发证书全面切换至 R46（RSA）、E46（ECC）专用 TLS 根，老 R3 根体系进入淘汰期。

这不是 CA 单方面动作，Chrome 根证书政策要求证书签发迁移到专用单一用途根证书层级，GlobalSign 只是按时间表执行。

根证书可以理解成发证机关的总公章，中间证书像办事处盖的业务章，最终证书是某次业务的凭证。浏览器和操作系统信任的是总公章，但总公章盖的范围越宽，吊销或轮换造成的波及面就越大。

Chrome 推单一用途根，就是让 TLS 证书、邮件证书、代码签名证书分开盖章。TLS 专用根只签 TLS 证书，根迁移或根吊销时，影响被限制在单一业务域。

Chrome Root Program 要求新根先完成预埋和审计，才能签发公开信任的 TLS 证书。GlobalSign 的 R46/E46 已经预埋一段时间，这次是正式从备用状态转正。

GlobalSign 这次 R46/E46 取代 R3，终端最直接的变化是证书链变了。老 R3 链是 GlobalSign Root CA R3 -> Organization Validation CA -> 站点证书，新链会变成 R46/E46 -> 对应中间 CA -> 站点证书。老客户端如果只内置 R3，没有 R46/E46，验证会直接失败。

用 openssl s_client 看链，常见的是 depth 2 报 unable to get local issuer certificate，Chrome 可能给 NET::ERR_CERT_AUTHORITY_INVALID。这类错误在过渡期不会大面积出现，但会集中在旧 Android、旧 Linux 发行版、企业内网自维护信任库的环境里。

小标题：迁移周期里最容易出问题的不是证书本身

很多团队只看证书到期时间，不看根证书信任链。续期时 CA 把链切到新根，服务端如果只配置站点证书不带中间证书，或者 Nginx 里写死旧中间证书路径，新链就会断。GlobalSign 迁移后，OV/EV 默认走 R46/E46，业务系统如果仍固定 R3 中间证书或固定证书链校验，8 月底之后新签证书可能出现客户端验证失败。开发环境和 CI 里用 curl 拉包、Java 程序用自定义 truststore 的，也要更新信任锚。

排查时可以先确认系统根库是否带 R46/E46。Debian/Ubuntu 下用 dpkg -L ca-certificates | grep GlobalSign 能看到新根文件，Java 侧用 keytool -list -cacerts | grep -i globalsign 检查 truststore。容器基础镜像如果太久，CA 包不更新，这类问题会在最不起眼的地方冒出来。

根策略变更会越来越频繁。Chrome 对根证书的淘汰节奏在加快，CA 的专用根也在增加，证书轮换、根迁移、中间证书更新会变成常规动作，不再是一年一次续期。

小标题：ACME 自动化把根迁移变成可重复执行的操作

ACME 协议把证书申请、验证、部署做成自动化流程，遇到根体系迁移时，重签证书和替换证书链的成本比手动低很多。Let's Encrypt、Google Trust Services、ZeroSSL 都支持 ACME，签发证书走各自专用根，证书链通常由客户端自动协商和补全。像 lcjmSSL 这类免费平台底层对接这几家 CA，支持多域名、泛域名和 IP 证书，提供 API，自动完成验证和部署，不用手工拼 intermediate bundle。它解决的不是单纯省钱，而是让证书链变更从一次人工排障变成自动化任务，私钥轮换也不再依赖人工拷贝。

回到 GlobalSign 迁移。如果业务里还有 OV/EV 证书依赖 R3 链，8 月 26 日之前要做的不是等新证书，而是先检查客户端信任库、中间证书配置、固定证书链校验逻辑。

证书自动化做得越早，这类根迁移对线上业务的影响就越低。