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

这周圈子里都在传一件事：Chrome 根计划要求公共可信的 TLS 根只保留 serverAuth 用途，不再承载 clientAuth。

GlobalSign 动作很快，7 月 27 号就把自己那套切干净了，DigiCert 定了明年 3 月 1 日切换，其他主流 CA 也在排队跟进。

很多同学第一反应是，这跟我有什么关系，我又不签发证书。可一旦你的服务里藏着双向 TLS（mTLS），关系就大了去了。

先把这个概念掰扯清楚。TLS 证书上有个字段叫 EKU（Extended Key Usage），翻译过来就是“这证书能干嘛”。常用的就那么几个值，serverAuth 表示它可以用来加密服务器和浏览器之间的 HTTPS 通信，clientAuth 表示它可以用来证明“我是谁”，也就是客户端身份。

大多数情况下这俩各管各的，公网服务器证书用 serverAuth，客户端用来登录、访问内部接口的证书用 clientAuth。

问题出在一批老证上。早年间不少企业图省事，申请一张公网 DV 甚至 OV 证书，既能挂到服务器上做 HTTPS，又顺手拿来当客户端证书做身份校验，一张证书两种用途全包。

加上 EKU 默认情况允许兼容，技术上倒也能跑。

但现在根计划把这扇门焊死了。公共可信的根上，clientAuth 这个用途被挪掉之后，你那张兼做 mTLS 客户端认证的公网证书，一旦到期续签，新的证书上就不再带 clientAuth EKU。对着发起 mTLS 握手，对端一查扩展字段，发现证书不满足校验条件，直接给你一个类似 handshake_failure 的报错，CLIENT_AUTH 压根走不通。

真要踩上这个坑，体验是相当糟糕的。证书不像代码，报错往往藏在很深处，白天排查半天，晚上服务静默重连，断断续续。业务线上不少系统是证书到期前自动续期，续完了才发现一堆下游服务起不来，运维只能三更半夜在机房熬夜重新签发临时证书。成本不是一两张证书的钱，是那个被反复打断的业务连续性。

往深处想，这是证书用途的边界问题，也是身份边界的问题。公网服务器证书，本质上是给全世界看的门牌号；内部客户端证书，本质上是公司内部的门禁卡。这两张卡本来就该分开管，混在一个根下面，既模糊了信任边界，也让安全策略没法精细化。一个外部进来的攻击者，如果拿到了带 clientAuth 的公网证书，理论上也能用它去撞你的内部接口，这种耦合本身就是个隐患。

所以这件事与其说是 CA 的合规调整，不如说是给所有做内部认证的企业敲了个警钟：公网的信任链和内部的信任链，趁早拆开。

拆的思路其实很成熟，就是公网身份和内部客户端身份分离。服务器的 HTTPS 证书继续走公共 CA，保持浏览器、App 都能信任；客户端身份这一路，改用企业自建的私有 PKI，签一套只为内部 mTLS 服务的独立根和中间 CA。

这样外部根怎么调整，都碰不到你内部认证的根基，续期、轮换、吊销全在自己手里，出了事故也能精准定位到是哪个环节的证书。

常见的做法无非两种：要么用开源那套自己搭 CA 服务，要么上企业级的证书管理平台。自建的好处是灵活，坏处是签名、生命周期、吊销管理的活全得自己扛，团队人力不够的话容易变成新的运维黑洞。有专门做这一块的证书管理中心，把根和中间 CA、批量签发、到期提醒、自动轮换都串起来，mTLS 场景就是套个配置的事，省心不少。

具体到落地，动作不用太大，但得排优先级。第一步先把还在用的双用途公网证书盘出来，逐台确认哪个服务把 HTTPS 证书同时又当客户端证书在用，这是一切的起点。

第二步给纯内部接口换私有 PKI 签的客户端证书，同步把服务端的信任库从那串公共 CA 换成你自己的内部根。第三步才是处理那些依赖外部证书的极端场景。

时间窗口其实是有的。GlobalSign 已经切了，DigiCert 到明年三月，正规的 DV/OV 证书续期窗口一般在一到三个月，趁着还没到集中到期点赶紧做，比到期那几天手忙脚乱强太多。

说句实在的，证书这东西平时没存在感，出问题的时候才要命。Chrome 根计划的这刀，砍得有点突然，但方向是对的——把一个混杂了公网和内部身份的老体系拆干净，长期看对企业没坏处。

手里还攥着双用途证书的，别等了，现在就是动手拆的最好时机。