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

GlobalSign 把 OV、EV 商业证书的根架构切换定在 8 月 26 日，新签发、重签发、变更域名的证书信任链会指向 R46 和 E46，存量证书继续走 R3。

这个动作不是简单的 CA 内部升级，它把兼容性风险推到了每张证书的下一次生命周期动作上。

根证书迁移这件事，可以类比成银行更换清算系统。

旧系统继续处理存量支票，新开账户全部走新系统，但商户手里的验钞机只认识旧系统的章。为了让商户不拒收新支票，银行在过渡期给新支票多盖一个旧系统的背书章，这个背书章就是交叉签名中间证书。设备验签时看到自己认识的旧根，就放行。

可以拿 openssl 看证书链。

正常新链会多出一段交叉证书，叶子证书由 R46 签发，交叉证书把 R46 连回 R3。老设备没有 R46 根证书，但看到 R3 根，就能建立信任。这个兼容窗口不是永久方案。

真正的坑在滞后性。证书没到期前，一切正常。一旦到期续费或重签发，新证书带着 R46/E46 链路下来，如果服务器没有部署完整证书链，或者终端没更新信任库，老终端、嵌入式设备、旧版 Java 程序会直接抛 unknown issuer。更麻烦的是做了证书固定的业务，客户端硬编码了 R3 根证书指纹，新链不匹配，TLS 握手直接失败。

报错不会只出现在浏览器。

POS 机、自助终端、IoT 网关、旧版 Android 系统、Java 1.8 以下环境都可能中招。javax.net.ssl.SSLHandshakeException 后面跟着 unable to find valid certification path to requested target，这类日志会先在监控里冒出来。那时候已经不是 CA 的问题，而是自己的证书资产没盘点清楚。

多数企业证书分散在不同云厂商、负载均衡、CDN、网关设备上，OV/EV 证书又是一年期居多，到期时间各不相同。这次迁移的影响会在未来一年内分批出现。

人工台账很难跟上，尤其是重签发时容易漏配中间证书和交叉证书。

行业里更明显的趋势是证书生命周期缩短。

Let's Encrypt 这类 ACME CA 把证书压到 90 天，Google Trust Services 也在推进短期证书。手动申请、验证、部署、续期的模式已经扛不住，自动化证书管理变成刚需。

lcjmSSL 这类支持 ACME 的免费证书平台，聚合 Let's Encrypt、Google Trust Services、ZeroSSL 等 CA，提供多域名、泛域名、IP 证书的自动申请和部署能力，也有简洁 API 可以对接内部系统。它解决的不是某一张证书的问题，而是把证书从申请到续期变成一条可重复执行的流程。遇到 GlobalSign 这种根迁移，能在测试环境里快速批量重签证书、下发完整链、做多终端验证，不用逐台登录服务器手工替换。

证书链验证有个简单原则：服务器必须返回完整链路，包括叶子证书和中间证书，根证书可以不返回。

交叉证书可以放在中间位置，但不要硬编码成唯一信任路径。openssl verify 配合 CAfile 能模拟终端校验，测试时把旧根、新根、交叉链分别组合，能提前发现 unknown issuer 的触发条件。

GlobalSign 这次 R3 到 R46/E46 的迁移不会是最后一次根架构调整。

CA 每隔几年就会做类似动作，交叉签名窗口有关闭时间。把证书管理从到期前手工换，改成自动续期、完整链下发、监控告警，才能在低频但高破坏的根迁移事件里少踩坑。