免费证书90天一轮，自动续期到底该走哪条路？ - *

　 一键部署OpenClaw

证书过期这件事，发现的方式通常只有一种：某天早上你自己打开站，浏览器先弹出一整页红色警告，然后你才意识到它已经过期了。免费证书普遍只有90天，一年要处理四次，靠记性去盯是不现实的，所以真正的选择不是“要不要自动化”，而是“用哪一种自动化”。而三种做法的差别，平时是看不出来的，只在出问题的那一刻才显形。

90天不是某一家的规定，而是免费证书的通行做法，并且这个数字还在往下走。Let’s Encrypt在2026年1月已经把有效期160小时的短期证书正式开放使用，同时明确说默认证书的有效期会在未来几年从90天一步步降到45天。趋势很清楚：留给手动操作的空间只会越来越小。反过来也是好消息：一旦把续期交给程序，90天还是45天，对你已经没有区别。

跑了自动续期，不等于证书在续

大部分情况下你不用自己配。用certbot这类工具装好之后，续期任务通常已经预置好了，可能是systemd的定时器，也可能是crontab里的一条记录。想看看到底有没有，执行systemctl list-timers找certbot，或者翻一下 /etc/crontab和 /etc/cron.d目录，有就是有，没有就得自己补一条。这一步花不了两分钟，但能排掉最常见的误判——不少人以为装好就万事大吉，其实定时任务压根没装上。

这里有个坑，很多人踩了却不知道。certbot renew的退出码只有在续期尝试失败时才是1；如果证书还没到该续的时候，它什么都不做，退出码同样是0。也就是说，脚本安安静静跑完、日志里没有报错，这两件事都不能证明证书真的续上了——它只能证明“任务执行过”。想知道到底续了没有，得看别的东西。另一个容易误读的信号是剩余天数：如果它长期停在某个数字上不动，那才是真的没在续。

官方给的频率建议是：90天的证书每60天续一次，6天的短期证书每3天续一次。另外还有一条容易被忽略的要求——例行续期不要在整点跑。凌晨零点、每个整点那一秒是全网最拥挤的时刻，官方明确要求客户端把执行时间随机化。certbot官方给出的cron样例就是每天0点和12点两次，每次先随机睡0到3600秒再执行。这个随机延迟不是可选项。官方专门解释过原因：整点集中请求会造成流量尖峰，服务繁忙时请求会被退回并要求稍后重试。

还有一件事千万别做：别用 --force-renewal去“试试能不能续”。它会无视到期时间，每跑一次就重新签一张，而你把这些次数用在了同一套域名上。Let’s Encrypt对“完全相同的标识符集合”限制是每7天5张，而且这一项不接受申请放宽。想验证续期链路通不通，正确做法是加 --dry-run，它会走预演环境、不写入磁盘，跑多少遍都不消耗额度。这也从侧面说明，正常的续期几乎碰不到限额——官方明确写过，例行续期基本不会触发速率限制，会撞上的多半是人为反复签发。

三条路，差别在出问题的时候

第一条路，在服务器上跑ACME客户端，certbot和acme.sh都属于这一类。它最通用，什么服务器、什么环境都能用，证书和私钥始终在自己手里，出了问题也能自己查。代价是这套东西得你自己维护：定时器在不在跑、系统重装之后有没有重新配、失败了谁能收到消息，都是你的责任。还有一点常被忽略：续期失败时你不会收到任何报错，三个月后浏览器弹出的那一页警告，才是它的第一封通知。

第二条路，交给云厂商或面板托管。腾讯云的证书托管能在新证书签发之后自动替换到它管的云***上，它的免费证书还会在到期前15天自动申请续期；阿里云的免费证书也可以自动完成DNS验证。这条路最省心，但边界也很清楚——它只覆盖它自己管的***，一旦你把证书用到别处，或者中途改了接入方式（比如换成CNAME接入），自动续期就可能静默失效，需要你重新申请一次。另外这类免费证书都不支持续期，到期只能重新申请，而且有年度额度上限，用超了就只能等下一年。

第三条路是DNS验证配通配符。一张证书覆盖一个主域下所有子域，子域多的站不用挨个申请。Let’s Encrypt的通配符证书必须走DNS验证，不能走文件验证。适合你的DNS服务商提供API、能自动写解析记录的场景；如果解析还得手动去点，那自动续期这件事就不成立了。反过来说，如果你的域名解析本来就托管在支持自动验证的服务商那里，通配符反而是最省事的方案，配一次可以管很久。

这里有个限制得单独说：云厂商的免费证书大多不支持通配符。腾讯云文档写得很直白，免费证书只支持单域名，不支持泛域名，也不支持绑定IP，一个账号最多申请50张；阿里云的个人测试证书免费版同样是单域名，每自然年20张，不支持续费，到期只能重新申请。所以子域多的站，要么走第三条路的DNS验证，要么就接受一张一张申请。这一点对子域多的站影响尤其大，因为每张证书都要单独走一遍验证流程，数量和额度都得提前算清楚。

三条路没有绝对的高下，判断标准可以简化成一句：出问题的时候，谁能第一时间告诉你。放在自己服务器上的，你得自己接一个通知；托管在云上的，你得确认它的续期确实触发了；配了通配符的，你得保证DNS的API密钥没失效。换句话说，选哪条路，取决于你更愿意维护哪一套东西，以及更怕哪种意外。

所以真正该配的不是“续期”，是“确认”。把部署动作挂到 --deploy-hook上，它只在续期真正成功之后才触发，这时候发一条消息给你，才算闭环；或者更笨但更稳的办法，定期跑一次openssl查证书剩余天数，低于阈值就告警。自动续期的价值不在于省下那几分钟操作，而在于它把“你记不记得”这件事从流程里拿掉了——证书不会提前打招呼，它只在到期的那一刻，替你毁掉访客对站点信任。续期失败不会有人通知你，但访客会看到。

申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！