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

GlobalSign 从2026年3月14日开始，把公开信任的 SSL/TLS 证书最长有效期从约398天缩短到199天，域名控制验证（DCV）重用期限限制在200天。CA/B论坛 Baseline Requirements 在3月15日生效，DigiCert、Sectigo 等主要 CA 同步调整签发策略。

续期频率直接翻倍，这不是某一家 CA 的商业动作，而是行业多年缩短证书生命周期计划的第一步。

对只有两三个证书的站点，199天感知不强。对证书数量几十张起步、域名分散在不同业务线和云账号里的团队，原来一年处理一次的证书台账，现在半年就要过一遍。审批、申请、下载、上传、重启、验证，任何一个环节拖几天，实际可用时间会更少。

先看一个容易误判的点。

199天不是单纯把到期时间提前，它真正影响的是续期窗口和验证节奏。以前一张证书可以用一年多，到期前30天人工处理都来得及。现在有效期半年，加上监控延迟、审批流程、多环境部署，往往刚换上没多久又进入下一轮续期。

DCV 重用期限同步缩短到200天，这个更麻烦。DCV 是证书签发前的域名控制权验证，常见方式有 HTTP-01、DNS-01。HTTP-01 需要在站点根路径放一个指定文件，DNS-01 要添加一条 TXT 记录。

验证通过后 CA 会缓存结果，现在缓存有效期被限制在200天。意味着即使证书没到期，验证缓存也可能先失效。等到续期时发现验证过不去，再临时补 DNS 记录或开放路径，很容易把续期窗口拖过去。

真实报错大家应该常见。浏览器侧是 NET::ERR_CERT_DATE_INVALID，服务端日志通常是 certificate has expired 或 SSL_ERROR_EXPIRED_CERT_ALERT。在199天周期下，这类问题从一年一遇变成半年一遇，而且多域名、泛域名证书只要有一个域名验证失败，整张证书都发不出来。

ACME 协议解决的正好是这个。可以把 ACME 理解成证书行业的自动扣费协议。

证书有效期缩短，相当于扣费周期变短，如果还靠人工去营业厅缴费，漏缴概率会随周期缩短明显上升。ACME 则让客户端和 CA 之间按照统一接口自动完成验证、申请、续期，人工只维护规则。

常见命令像这样：

acme.sh --issue -d example.com -d '*.example.com' --dns dns_cf

或者 certbot renew --dry-run 先跑一遍续期预检。证书签发后，通过 deploy hook 推到 Nginx、Kubernetes Secret 或 SLB。

这个过程把原本需要手工操作的下载、上传、重启变成一次脚本执行。ACME 客户端支持提前触发续期，例如剩余30天开始尝试，半年有效期下可以把阈值适当调大，别等到最后几天再动作。

企业环境里只装一个 ACME 客户端还不够。证书种类多，业务侧有单域名、多域名、泛域名，有时还要给内网或公网 IP 申请证书。上游 CA 对验证方式、速率限制、IP 证书支持也不同。运维需要一个统一出口，避免每台机器各配一套脚本、各存一份账号。现在有一些免费平台把这类能力封装好，比如 lcjmSSL 基于 Let's Encrypt、Google Trust Services、ZeroSSL 等支持 ACME 的 CA，提供多域名、泛域名和 IP 证书的申请接口，自动完成验证和部署。它更像证书生命周期的统一代理，业务系统通过 API 拿证书，不用感知上游 CA 的策略变化。

落地时可以把证书管理从业务配置里剥离出来。

Ingress 控制器或网关通过挂载目录和 reload 机制读取最新证书，CI/CD 在发布流程里加一步证书预检。平台侧负责提前续期和到期提醒，而不是等监控告警。混合环境里还有一些无法自动 reload 的旧 Nginx 或 SLB，把这些点收敛到统一证书网关，比逐台改造更现实。

199天还会继续缩短，CA/B 论坛已经把这作为多年计划的第一步。

现在把自动化验证、自动部署、统一 API 这条链路跑通，后面再调整周期时，基本不用改架构。