certbot renew 未自动续证主因是系统定时任务未配置或权限不足;需检查 systemd timer/cron 是否存在,再用 --install-cron-job 或手动添加 crontab,并确保 --post-hook 重载 web 服务。

certbot renew 命令为什么没自动续上证书
绝大多数“自动续期失败”不是因为没跑 certbot renew,而是它根本没触发——系统级定时任务(比如 systemd timer 或 cron)压根没配,或者配了但没权限读写 /etc/letsencrypt/。默认情况下,certbot 不会自己注册定时任务,装完就完事了。
实操建议:
立即学习“Python免费学习笔记(深入)”;
- 检查是否真有定时任务:运行
sudo systemctl list-timers | grep certbot(systemd 系统),或sudo crontab -l | grep certbot(cron 系统) - 如果没有,别手写 cron 行,直接用官方推荐命令安装:
sudo certbot renew --dry-run成功后,再执行sudo certbot renew --install-cron-job(部分版本支持);否则手动加一行到 root 的 crontab:0 12 * * 1 /usr/bin/certbot renew --quiet --post-hook "/bin/systemctl reload nginx" -
--post-hook很关键:续期后必须重载 Web 服务,否则旧证书还在内存里,浏览器看到的仍是过期的
acme 客户端(如 acme.sh)和 certbot 的 renew 行为差异
acme.sh 默认不依赖系统服务管理器,它的 --renew 是纯脚本逻辑,每次执行都查证书剩余天数,满足条件才续;而 certbot renew 是批量扫描所有证书,只要任一证书距过期 ≤30 天就全量处理——这意味着你可能在日志里看到“Skipping X.com (expired)”却仍触发了其他域名续期。
实操建议:
立即学习“Python免费学习笔记(深入)”;
- 用
acme.sh --list查看每个域名的到期时间,比certbot certificates更直观 -
acme.sh的--force和certbot的--force-renewal都慎用:前者会绕过本地缓存直接走 ACME 协议,后者可能被 Let’s Encrypt 限频(7 天内同一域名最多 5 次) - 路径差异:acme.sh 默认把证书放在
~/.acme.sh/,certbot 放在/etc/letsencrypt/,Web 服务配置里千万别引错路径
续期失败时常见的 DNS-01 验证卡点
DNS-01 验证失败几乎从不报“DNS 错误”,而是表现为 urn:ietf:params:acme:error:dns 或更隐蔽的 Timeout during connect——本质是 ACME 服务器查不到你刚设的 TXT 记录,原因通常是 DNS 未生效、TTL 过长、或 API 凭据权限不足。
实操建议:
立即学习“Python免费学习笔记(深入)”;
- 别等
certbot renew自己去查:先手动触发验证并观察过程:certbot certonly --manual --preferred-challenges=dns -d example.com,它会打印要设置的 TXT 值,你设完后用dig -t txt _acme-challenge.example.com确认返回值一致 - 云厂商 DNS API(如阿里云、Cloudflare)需确保 AccessKey 有
Alidns:DescribeDomainRecords和Alidns:AddDomainRecord权限,只给Read不够 - 本地 DNS 缓存干扰:Mac 上跑
sudo dscacheutil -flushcache,Linux 上可能是sudo systemd-resolve --flush-caches,但更可靠的是直接用dig查权威服务器(加@8.8.8.8)
证书续期后 Nginx/Apache 仍用旧证书
这不是证书没续成,而是 Web 服务没加载新文件。常见于配置中硬编码了证书路径(比如 ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem),但没注意到 fullchain.pem 是符号链接,指向实际日期命名的子目录——而某些部署脚本或监控工具会把它“固化”成绝对路径。
实操建议:
立即学习“Python免费学习笔记(深入)”;
- 永远用
live/下的符号链接路径,别用archive/里的具体文件名;检查链接是否断裂:ls -l /etc/letsencrypt/live/example.com/fullchain.pem - Nginx 必须
reload(不是restart),否则 worker 进程仍持旧文件句柄;Apache 要sudo a2ensite后再systemctl reload apache2 - 验证是否生效:用
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates,看notAfter是否更新
证书路径、服务重载、DNS 生效这三环,任意一环断掉,都会让你以为自动续期“失效”——其实它早跑完了,只是没人告诉 Web 服务该换人了。










