为什么 Let's Encrypt 证书到期前 30 天自动续签任务没有触发?

文章导读
大多数情况下是系统定时任务被禁用或执行报错,建议先手动执行续签命令恢复服务,再排查自动化配置。
📋 目录
  1. 命令速用版
  2. 为什么会这样
  3. 分步处理
  4. 怎么验证是否生效
  5. 常见坑
  6. 参考来源
A A

大多数情况下是系统定时任务被禁用或执行报错,建议先手动执行续签命令恢复服务,再排查自动化配置。

先说结论:自动续签依赖系统定时任务(cron 或 systemd timer),任务未触发通常是配置失效或前置检查未通过。

  • 先确认:检查 certbot.timer 或 cron 任务是否处于活跃状态
  • 先处理:手动运行续签命令确保当前证书有效
  • 再验证:查看日志确认定时任务后续能正常执行

命令速用版

如果你使用的是 Certbot 且系统基于 systemd,可以直接运行以下命令检查状态和测试续签:

systemctl status certbot.timer
certbot renew `--dry-run`

如果 `--dry-run` 通过,说明续签逻辑正常;如果失败,会根据报错信息定位问题。

为什么会这样

Let's Encrypt 证书有效期为 90 天,客户端通常设置在到期前 30 天尝试续签。这个过程不是证书自带的功能,而是依赖服务器上的定时任务守护进程。如果服务器重启过、更新过系统包、或者磁盘空间满了,都可能导致定时任务沉默失败。此外,网络波动或防火墙规则变更也会让续签请求被拦截。

分步处理

1. 检查证书当前状态
确认证书是否真的快到期了,避免误操作:

openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem -noout -dates

注意:请将 example.com 替换为你的实际域名。

为什么 Let's Encrypt 证书到期前 30 天自动续签任务没有触发?

2. 检查定时任务状态
对于大多数现代 Linux 发行版,Certbot 使用 systemd timer:

systemctl list-timers | grep certbot
systemctl status certbot.timer

如果显示 inactive 或 disabled,需要启用它:

systemctl enable `--now` certbot.timer

3. 手动尝试续签
先解决当前危机,再排查自动化:

certbot renew

如果手动成功但自动失败,问题集中在定时任务环境上。

怎么验证是否生效

1. 查看日志
Certbot 日志通常位于:

/var/log/letsencrypt/letsencrypt.log

使用 grep 快速筛选续签相关记录:

为什么 Let's Encrypt 证书到期前 30 天自动续签任务没有触发?
grep "renewal" /var/log/letsencrypt/letsencrypt.log

查看最近是否有 "Successfully renewed" 字样。

2. 浏览器检查
刷新网站,点击浏览器地址栏锁形图标,查看证书有效期是否已更新。

3. 命令行验证
使用 openssl 再次检查到期时间,确认是否延后了 90 天。

常见坑

1. 频率限制(Rate Limits)
不要频繁强制续签。Let's Encrypt 有严格的速率限制,短时间内多次失败可能导致被封锁一周。测试时务必加 `--dry-run` 参数。

2. Web 服务器未重载
证书文件更新了,但 Nginx 或 Apache 没有重载配置,网站依然用旧证书。确保证书续签钩子(hooks)配置正确,或手动重载:

systemctl reload nginx
# 或
systemctl reload apache2

3. 磁盘空间不足
如果磁盘满了,日志写不进去,续签脚本可能直接退出而不报错。

参考来源

  • Certbot Documentation - Automating renewal (https://certbot.eff.org/docs/)
  • Let's Encrypt FAQ - Certificate Lifetime (https://letsencrypt.org/docs/faq/)
  • Let's Encrypt Rate Limits (https://letsencrypt.org/docs/rate-limits/)