Let’sEncrypt7月8日正式停止签发TLS客户端认证证书，mTLS架构需尽快迁移

依据Let’sEncrypt官方公告，2026年7月8日将永久关闭tlsclientACME配置文件，彻底停止签发带有TLSClientAuthentication扩展密钥用法（EKU）的证书。此次调整意味着企业无法再使用Let’sEncrypt证书实现mTLS双向认证。

大量运维人员容易产生误区：普通网站HTTPS证书不受任何影响，仅依靠客户端证书完成双向身份校验的业务会遭遇冲击。该政策落地源于CA/B浏览器论坛规范以及谷歌根证书项目要求，公共CA必须区分服务器证书与客户端证书信任体系，不能混用一套证书同时承担服务端加密与客户端身份认证。

本次变更经历长时间过渡期，2026年2月默认classic配置已移除客户端认证字段；5月13日关闭tlsclient配置新用户注册；7月8日为最终截止点。原有已签发证书在有效期内仍然可用，但到期后无法完成续期。 

一、哪些业务场景会受到直接冲击？

TLS客户端证书多用于mTLS双向认证，以下架构需重点排查：

1、微服务与服务网格通信：K8s集群、Istio、Linkerd依靠客户端证书实现服务之间身份核验，防止内网未授权服务非法调用接口。

2、物联网IoT设备接入：传感器、工业终端使用客户端证书接入云端平台，替代密钥完成设备可信认证。

内网网关、VPN与后台管理系统：利用客户端证书限制人员、设备访问敏感后台，作为接入第一道安全门槛。
3、上下游企业API对接：合作伙伴之间采用mTLS建立加密通道，依靠证书识别调用方身份。

若运维未及时迁移，现有证书到期续期时，新证书缺失clientAuth标识，双向认证握手失败，直接引发接口中断、设备离线等线上故障。

二、技术原理：EKU字段是双向认证关键门槛

X.509证书依靠扩展密钥用法EKU定义证书用途。常规HTTPS证书仅包含服务器认证标识；支持mTLS的证书同时具备serverAuth与clientAuth。

7月8日后Let’sEncrypt所有新证书不再写入客户端认证字段。即便强行部署普通证书作为客户端凭证，Nginx、Apache、API网关等组件会判定证书用途不符，拒绝完成TLS握手。

简单来说：证书用途与业务场景不匹配，系统直接阻断通信，不属于程序Bug，属于标准安全校验机制。

三、主流迁移方案对比，企业按需选型

方案1：搭建私有CA

使用OpenSSL、StepCA、Vault自建内部证书体系，自主签发客户端证书，完全不受公共CA政策约束。适合微服务、IoT、大规模内网业务，能够自主控制证书有效期、吊销列表、信任策略。缺点是需要投入人力维护PKI体系。

方案2：选用支持客户端证书的商业CA

DigiCert、Sectigo等商业证书服务商依旧提供独立客户端认证证书，适合对外合作伙伴对接、有合规审计需求的政企单位。

方案3：调整架构，弱化mTLS依赖

部分业务可改用OAuth2、JWT令牌、API密钥等方式替代客户端证书，适合轻量级外部接口，但安全强度低于双向TLS，不建议高敏感内网场景使用。

四、运维自查与迁移实施清单

1、资产盘点：扫描全网证书，筛选存在TLSWebClientAuthenticationEKU的证书，标注到期时间。

2、区分业务优先级，先完成生产核心业务迁移，测试环境先行验证。

3、同步更新服务端信任根证书，导入私有CA根证书或者商业CA证书链。

4、制定轮换计划，避免集中批量更换证书引发业务波动。

5、上线监控告警，持续观测TLS握手异常日志，及时发现认证失败问题。

五、行业总结

Let’sEncrypt停止客户端证书签发，是全球公共CA规范化发展的标志性事件。今后公共免费证书定位将聚焦于互联网公开网站HTTPS加密，企业内网、设备身份、服务间认证场景，将逐步转向私有PKI体系。

对于运维团队而言，切勿等到证书集中到期再应急处理，建议提前完成架构改造。免费证书不再适用于mTLS场景，企业需要重新规划零信任、双向认证基础设施，避免出现突发性业务中断。