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

2026年5月13日，Let's Encrypt 做了两件事。tlsclient ACME 配置文件对新账户关闭，7月8日完全弃用。

tlsserver 配置文件开始可选签发 45 天证书。两条消息放在一起看，指向一个变化：证书正在按用途分家，同时轮换周期继续缩短。

先看 tlsclient。

这个配置文件签发的证书带 TLS Web Client Authentication EKU，用途是 mTLS 里的客户端身份证明。Generation Y 中间 CA 故意去掉这个 EKU，是为了提前对齐 CA/Browser Forum 客户端与服务端认证分离的要求。打个比方，服务端证书像园区大门门禁卡，客户端证书像员工工牌。过去一张卡既能开门又能当工牌，现在门禁系统只认门禁卡，工牌必须单独发。

ACME 协议在 2025 年引入 profile 参数后，newOrder 请求里可以指定 profile。Let's Encrypt 的 tlsserver、tlsclient、classic 三个配置文件就是这么来的。旧客户端不传 profile，默认走 classic，所以大多数服务端证书暂时不受影响。但如果脚本里显式写了 tlsclient，新账户会直接撞上服务端拒绝。

实际报错类似这样：

urn:ietf:params:acme:error:unauthorized: The ACME server is not able to issue a certificate for the 'tlsclient' profile

新账户看到这个，不用再调参数，得换方案。

企业里 mTLS 常见于服务网格、微服务间调用、IoT 设备接入。

以前不少团队靠 Let's Encrypt 免费签客户端证书。现在新账户不能签，老证书到期后也要迁走。迁移时最容易踩的坑不是算法，是资产清单。客户端证书散在虚拟机、容器、边缘设备里，很多连负责人都不清楚，要把它们找出来、归类、改签发流程，工作量比想象中大。

lcjmSSL 这类平台在这件事上能省点事。它把 ACME 的 profile 适配做进了自动申请和 API，按用途选择 tlsserver 或 classic，不用自己在客户端里试错。多域名、泛域名、IP 证书可以放进同一个自动化流程。国内环境下，它还屏蔽了 Let's Encrypt、Google Trust Services、ZeroSSL 几个上游 CA 的差异，API 调用保持一致。

45 天证书这边，2028 年 2 月成为默认。

经典配置文件 2027 年 2 月切到 64 天，再切到 45 天。对运维来说，45 天意味着一年要轮换 8 次以上。手工更新不现实，必须靠自动化。

45 天证书对分布式系统还有一层影响。证书在网关更新后，边缘节点、CDN、负载均衡如果不同步，用户会看到证书链错误。自动化流程必须把证书推送、reload、健康检查串起来。

很多团队先更新中心节点，再等边缘节点过期，排查时才发现是节点本地缓存了旧证书。这类问题在 90 天周期里不常暴露，缩到 45 天后会频繁出现。

可以用这个命令快速看证书剩余天数：

echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates

如果 notAfter 距现在不足 15 天，监控就该告警。短周期证书把告警阈值从 30 天压到 7 到 10 天才合理，不然每天都是噪音。

有团队想继续用 90 天证书拖着。短期可以，但经典配置文件的切换时间表已经定死。拖到 2027 年再改，等于在证书系统上叠两年技术债。

到 2028 年默认 45 天时，所有依赖旧周期做容量规划、审计、合规检查的流程都会被动。

这次调整不是 Let's Encrypt 一家的动作。CA/Browser Forum 在推客户端与服务端认证分离，短周期证书也是行业方向。

运维要做的不是观望，而是把证书生命周期从按年维护改成按周自动轮换。ACME 自动化能力已经从可选变成必选。