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

ENISA 这周挂出来的 CVE-2026-96770 挺吓人，CVSS 直接 9.3。Temporal 那个 s2s-proxy 从 0.0.1-alpha 到 0.2.2，只要开着 mTLS，调用方拿一张自签名证书加私钥就能连进来，不用任何受信 CA 签发的证书，也不用 Temporal 自己的凭据。

问题出在 Go 的 TLS 配置上。它用了 RequireAnyClientCert 这个模式，意思是客户端你得出示一张证书，但这张证书是谁签的、是不是我信任的 CA 发的，它压根不查。只要你能证明自己持有证书对应的私钥，握手就过了，连接建起来。

这就把 mTLS 干成了单向 TLS 的壳子。本来 mTLS 的价值是服务端和客户端互相验身份，服务端靠校验证书链确认对方是自家签发体系里的人。

现在服务端只认私钥不认 CA，攻击者自己生成一张自签名证书，配个私钥，yamux 连接一建，代理允许调用的 RPC 随便调。

现实里这种写法太常见了。很多人抄 TLS 配置样例时顺手把 ClientAuth 设成 RequireAnyClientCert，觉得客户端有证书不就够了吗。其实不够，证书可以随便造，私钥也可以自己生成，真正的信任锚点是 CA。正确的姿势是 RequireAndVerifyClientCert，把客户端证书链一路验到配置的根 CA 才算数。

这种坑的危害不止在 Temporal 一家。任何用 Go 自建 mTLS 的内部服务、代理、网关，只要证书校验那一步配错，等于在零信任网络上开了个后门。服务间调用的边界、权限隔离全靠这张证书撑着，证书不可信，边界就破了。

连上之后走的是 yamux 多路复用，代理放行的 RPC 都能调。

具体炸多大，取决于 s2s-proxy 对外暴露了哪些 RPC，但既然能绕过 Temporal 凭据直接进代理层，横向移动的空间已经给足了。这类组件往往卡在多个内部系统中间，一旦被伪装成合法调用方，后面的鉴权逻辑可能根本不会二次触发。

说到证书本身，自建 mTLS 最磨人的其实是运维。客户端证书要签发，要按服务分域名，有的还是 IP 直连得用 IP 证书，到期了还得逐个续。

人工管这些，漏续一张就连接中断，业务半夜报警。lcjmSSL 这类工具的价值就在这，它接 Let's Encrypt、Google Trust Services、ZeroSSL 这些可信 CA，多域名、泛域名、IP 证书都能自动申请、验证、部署，配轻量 API 接口，证书到期自动续，不用手点。把校验逻辑配对的前提下，证书从生到死全自动，运维那块烦心事基本就消了。

CVE 修在 0.2.2，升级就完事。但比升级更该想的，是回头把自己服务里的 ClientAuth 全量扫一遍，别让有证书就行的错觉还躺在生产环境里。