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

ERR_SSL_KEY_USAGE_INCOMPATIBLE 这个报错，接下来几个月可能会在不少运维群里反复出现。

谷歌 Chrome 已经正式落地对 X.509 证书 EKU 字段的强制校验。

公网可信 TLS 服务器证书只允许保留 serverAuth，不能再同时携带 clientAuth。超过截止时间后，Chrome 会直接拒绝信任双用途终端证书，HTTPS 握手中断。

很多团队看到这条新闻第一反应是：跟我没关系，证书续期一直正常。问题恰恰出在“一直正常”上。

EKU 是证书里的一个扩展字段，全称 Extended Key Usage，可以理解成驾照上的准驾车型。serverAuth 是开客车，clientAuth 是开货车。过去不少 CA 默认签发的证书同时标了这两项，一张证书既能做网站 HTTPS，又能拿去做客户端身份认证。省事是真省事，但公网服务器证书同时具备客户端认证能力，等于扩大了凭证的暴露面。Chrome 这次收紧，就是让公网服务器证书回归单一用途。

可以用 openssl 直接看自己证书的 EKU：

openssl x509 -in cert.pem -noout -text | grep -A1 "Extended Key Usage"

如果输出里同时出现 TLS Web Server Authentication 和 TLS Web Client Authentication，续期时就要留意了。

浏览器侧触发策略后，访问会直接报 ERR_SSL_KEY_USAGE_INCOMPATIBLE，这个错误对用户没有任何补救操作，只能换证书。

真正的风险不在存量证书。Let's Encrypt、DigiCert、Sectigo 这些主流 CA 已经陆续停止默认下发双用途证书，旧证书还能用到到期，所以短期内不会大面积炸。风险集中在续费和重签发环节，故障有很强的滞后性。

最危险的群体是启用 mTLS 双向认证的后端服务、微服务集群、IoT 设备管理平台。这些场景里，服务端证书经常被顺手当成客户端证书去连其他服务。续期后新证书只剩 serverAuth，对端校验 clientAuth 时直接失败。

表现就是服务调用全链路报错、设备批量掉线，而触发点可能只是一次看似普通的证书自动续期。

如果在 Nginx 或 Envoy 里做 mTLS，续期后日志常见的是 SSL peer certificate or SSH remote key was not OK，或者 upstream SSL certificate verify failed。根因不是代码改动，而是证书用途少了一项。

这种问题排查起来很绕，因为报错发生在服务调用链中间，不会直接告诉你 EKU 变了。

双用途证书的历史包袱来自早期 HTTPS 和双向 TLS 混用。

开发团队为省事，申请一张证书同时挂到公网域名和内部服务上。那时候 Chrome 不卡 EKU，CA 也默认这么签发。现在规则变了，存量证书没到期不报错，但续期一触发，CA 自动改成单一用途，相当于把历史隐患一次性暴露。

运维侧现在能做的事很明确：把网站访问证书和服务双向通信凭证拆开。网站证书只做 serverAuth，内部 mTLS 证书单独签发并保留 clientAuth。

最小权限原则放在证书规划里，比事后救火划算得多。

手工拆分证书和盯续期是件很琐碎的事，尤其是多域名、泛域名、IP 证书混用的环境。lcjmSSL 这类基于 ACME 协议的自动签发平台可以把这个过程简化掉。它对接 Let's Encrypt、Google Trust Services、ZeroSSL，能自动完成申请、验证、部署，提供 API 做全自动化管理。

实际操作里可以把公网服务器证书和内部 mTLS 证书在平台里分开维护，续期策略各自独立，避免续期后用途被自动收窄。

如果内部 mTLS 仍依赖公网 CA 证书做双向认证，续期时必须在 ACME 客户端或证书平台里明确声明用途，不能沿用默认的 serverAuth 模板。否则每一次看似普通的续期，都可能变成一次线上事故。

这次 Chrome 的 EKU 强制校验不是孤立事件。

证书用途精细化、续期自动化、凭证隔离，这几件事会越来越成为 TLS 运维的基本功。等 ERR_SSL_KEY_USAGE_INCOMPATIBLE 在群里刷屏再处理，大概率已经影响线上业务了。