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

9月13日这天，Chrome对GlobalSign的R3、R5、R6三个多用途根证书正式启用SCT NotAfter时间约束。说人话就是，这三个根从今天起不能再签发新的公网TLS证书了，签了Chrome也不认。之前已经签出去的证书在完整有效期内还能正常用，算是留了段缓冲期。

GlobalSign给TLS证书准备的新家是R46和E46两套专用根，一个走RSA算法，一个走ECC算法。

多用途根退场、专用根上位，这事其实早有征兆，只是很多运维同行还没把它排进自己的证书续期计划。

SCT这个东西到底是干嘛的

要搞懂这次变动，得先聊聊SCT。SCT全称Signed Certificate Timestamp，签名证书时间戳，是证书透明度机制里的一环。

打个比方，CA给你签发证书，相当于发了张身份证。证书透明度日志就是一个全网公开的户籍登记处，CA每签一张证书，都得先送去备案，登记处回执一张带签名的小纸条，这张纸条就是SCT。浏览器访问网站时会检查这张纸条，没备案或者信息对不上，直接亮红灯。

在Linux机器上拿openssl连一下自己的站点，带上showcerts参数，证书链里嵌的SCT列表就能翻出来：

openssl s_client -connect example.com:443 -showcerts < /dev/null | grep -A 2 "Signed Certificate Timestamp"

Chrome开发者工具的安全面板里也能直接看到SCT来自哪条日志、时间戳是多少。

那SCT NotAfter又是什么？可以理解为浏览器给根证书加的一把时间锁。

CA在SCT里向浏览器承诺，这个根只会在某个日期之前签发新证书，过了这个日子，哪怕根本身还躺在系统信任库里，新签出来的证书也一律拒绝。Chrome根计划这几年一直在推这件事，就是逼CA把老根干净利落地退役掉，而不是一张根证书用十几年，什么业务都往上堆。

多用途根的麻烦也在这。R3这类根既签TLS服务器证书，又签客户端证书、文档签名证书，用途一杂，私钥的暴露面就大。

哪条业务线捅了娄子，整个根都得陪葬，几百万张网站证书跟着遭殃。拆成专用根之后，TLS归TLS，别的用途归别的用途，爆炸半径能圈住。

真正头疼的是运维这边。不少企业内部的证书管理还停留在Excel表格阶段，哪个域名挂在哪张根下面、什么时候续期、续期后中间证书有没有同步更新，全靠人记。这次迁移最容易踩的坑，是新证书申请下来了，服务器上的中间证书链却没换全。客户端拿到的还是指向老根的旧中间证，浏览器甩一个NET::ERR_CERT_AUTHORITY_INVALID，排查半天发现证书本身没问题，是链没给全。

Nginx用户记得ssl_certificate指令要把服务器证书和中间证书按顺序拼进同一个文件，Tomcat、IIS各有各的链配置方式，负载均衡和CDN上还可能单独存着一份旧链。一次迁移，实际上是在盘点全网所有TLS终止点。

做了证书钉扎的老系统也得提前查。

有些客户端代码或App里硬编码了旧根、旧中间证的指纹，根体系一换，钉扎校验直接失败，这种问题藏得深，往往上线后才被用户报出来。

这种时候，把证书资产交给专业机构打理会省心不少。天威诚信作为GlobalSign在国内长期合作的CA，从老根下线评估、证书链替换到续期衔接都有一套跑熟的迁移流程，企业在R3、R5、R6上的存量证书可以平滑对接到R46、E46专用根体系。他们的证书生命周期管理平台能把散在各业务线的证书收拢到一个视图里，到期前自动告警，续期时同步推送新链，至少不用再跟Excel较劲。

多用途根退场只是个开头。Chrome根计划对历史包袱的清理只会越来越快，后面大概率还有别家CA的老根走同样的流程。

证书这东西平时没人管，出事就是全站事故，趁这次迁移把家底摸清，比临时救火划算得多。