原来 Certbot 的自动更新默认使用的是 systemd 定时器。

2026.08.20

• 基础设施

2

9

大家好，我是Kita。
虽然标题听起来像轻小说，但这篇文章是关于Let's Encrypt的。

最近，我们运营的一个网站的SSL证书过期了。
作为一名基础设施工程师，这确实有点尴尬，但正因如此，我才意识到自己长期以来的一个误解。

我一直以为“ Let's Encrypt 自动续订 = cron”。然而，经过调查，我发现 AlmaLinux 9 + Certbot 3.x默认使用systemd 定时器而不是 cron。

此外，导致此次到期的原因既不是上述任何一种，而是完全不同的其他原因。

这次，我将以备忘录的形式总结我在实际事件响应过程中调查的内容以及我学到的东西。

先说结论（给那些时间紧迫的人）

• AlmaLinux 9（EPEL 版本的 Certbot）的自动更新而不是由 cron 处理。certbot-renew.timer）
• 即使计时器正在运行，更新仍可能根据身份验证插件的设置而继续失败。
• 如果证书过期，请按以下顺序检查： systemctl list-timers → journalctl -u certbot-renew.service
• 应该使用部署钩子来自动化将更新反映到 Web 服务器的过程。

下面按实际运作顺序解释整个过程。

一天突然出现的问题

有一天，当我访问我们新推出的服务的网站时，浏览器中突然出现一个警告页面，提示SSL证书已过期。

这可糟了。

Let's Encrypt 证书的有效期仅为 90 天，因此自动续期是正常运行的先决条件。
反之，如果证书过期，则意味着流程中的某些环节未实现自动化。

我的第一反应是：“等等，我不是设置了 cron 任务吗？”
于是我立即检查了大家最常用的 cron 任务。

$ sudo crontab -l $ sudo cat /etc/crontab $ sudo ls /etc/cron.d/

嗯，这里什么都没写。

我一开始想，“也许我漏掉了某个设置……”，但这说不通。
即使定时任务是空的，更新之前也一直都很成功。

我进一步调查后，发现了这些信息。

最新版本的 Certbot 使用 systemd 定时器。

哦，真的吗？我还是第一次听说。

Certbot 的自动更新不一定是通过 cron 完成的。

这一点在官方文档中其实已经明确说明。 《Certbot 用户指南》的“自动续订”部分指出，大多数 Certbot 安装都预配置了自动更新，您可以通过查看crontab（ /etc/crontab或/etc/cron.*/* ）或 systemd 定时器（ systemctl list-timers ）来检查这一点。

“请在系统的 crontab（通常是 /etc/crontab 或 /etc/cron.*/*）
或 systemd 定时器

来源： Certbot 用户指南“自动续期”

换句话说，自动更新并非总是通过 cron 实现的；具体方法似乎取决于发行版和软件包。
在本例中，适用于 AlmaLinux 9 的 EPEL 版 Certbot 使用的是 systemd 定时器方法。

我们来检查一下systemd定时器。

$ sudo systemctl list-timers | grep certbot

以下是结果。

令人惊讶的是，certbot-renew.timer竟然在运行。

换句话说，自动更新从一开始就已配置好，无需编写任何一行 cron 代码。

cron 和 systemd 定时器的区别

既然说到这儿，我们就简单总结一下两者的区别。
从操作角度来看，查看日志和状态的便捷性要好得多。

然而，这就引出了一个问题：自动续订功能一直正常，
为什么会过期呢？

为什么过期了？原因是身份验证方法的问题。

证书在计时器运行时过期，
这表明续订过程尝试过但反复失败。
我们来查看日志。

$ sudo journalctl -u certbot-renew.service --since "yesterday" | grep -i error Jul 01 11:12:29 ip-172-26-9-○○.ap-northeast-1.compute.internal certbot[355188]: 证书 www.server-camp.com 续订失败，错误信息：手动插件无法正常工作；您的现有配置可能存在问题。 Jul 01 11:12:29 ip-172-26-9-○○.ap-northeast-1.compute.internal certbot[355188]: 错误信息：PluginError('使用手动插件非交互方式时，必须使用 --manual-auth-hook 提供身份验证脚本。')

$ sudo cat /etc/letsencrypt/renewal/www.server-camp.com.conf | grep authenticator authenticator = webroot

$ sudo certbot renew --dry-run 正在将调试日志保存到 /var/log/letsencrypt/letsencrypt.log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 正在处理 /etc/letsencrypt/renewal/www.server-camp.com.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 正在模拟 www.server-camp.com 现有证书的续期 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 恭喜，模拟所有续期均成功：/etc/letsencrypt/live/www.server-camp.com/fullchain.pem (成功) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

“恭喜，所有模拟续订均已成功”表明续订过程已成功完成。接下来，我将检查服务状态。

$ sudo systemctl status certbot-renew.service ○ certbot-renew.service - 此服务自动续订找到的任何 certbot 证书 Loaded: loaded (/usr/lib/systemd/system/certbot-renew.service; static) Active: inactive (dead) since Mon 2026-07-06 07:16:35 JST; 4小时10分钟前 触发者：● certbot-renew.timer 进程：392173 ExecStart=/usr/bin/certbot renew --noninteractive --no-random-sleep-on-renew $PRE_HOOK $POST_HOOK $RENEW_HOOK $DEPLOY_HOOK $CERTBOT_ARGS (code=exited, status=0/SUCCESS) 主进程ID：392173 (code=exited, status=0/SUCCESS) CPU：333毫秒

$ sudo vi /etc/letsencrypt/renewal-hooks/deploy/reload-httpd.sh

#!/bin/bash systemctl reload httpd

$ sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-httpd.sh

证书续期（成功后）↓ 执行部署钩子 ↓ Apache 重新加载 ↓ 新证书立即生效

A. 我不建议这样做。
certbot renew 本身只会续订即将过期的证书，因此运行两次实际上危害很小，但有两个执行源意味着日志分散在不同的位置，这会使故障排除更加复杂。
最好坚持使用发行版的标准方法。

问：certbot.timer 和 certbot-renew.timer 有什么区别？

A. 内容相同，都是 Certbot 自动续期 systemd 定时器；只是名称因软件包而异。基于 RHEL 的系统，例如 AlmaLinux 9（EPEL 版本），使用certbot-renew.timer ；Debian/Ubuntu（apt 版本）使用certbot.timer ；而 snap 版本使用snap.certbot.renew.timer 。您可以使用`systemctl list-timers | grep certbot`命令在任何环境中进行检查。

如果您觉得这篇文章对您有帮助，请点个“赞”！

2

加载中...

2

9