Question

我看到了相互矛盾的建议。来自eff.org docs：

如果您正在设置cron或systemd作业，我们建议您每天运行两次...请在一小时内随机选择续订任务。

我也看到了weekly jobs的建议。

我不是cron专家，所以我更倾向于使用详细步骤来设置cron作业。

Answer 1

所以我决定安排它每天运行一次。首先，我将自动续订测试为the docs recommend：

sudo letsencrypt renew --dry-run --agree-tos

然后我更新了crontab：

sudo crontab -e

这是我添加的行：

12 3 * * *   letsencrypt renew >> /var/log/letsencrypt/renew.log

这是在凌晨3:12进行的续订。我认为文档建议＆＃34;在一小时内随机分钟＆＃34;在续订服务器上分配负载。所以我认为除了0,15,30或45之外的任何东西都是首选。

我在cron设置中查看了randomizing the minute，就像Jenkins允许的那样。在原始的EEF页面上是这个例子：

0 0,12 * * * python -c 'import random; import time; time.sleep(random.random() * 3600)' && /usr/local/bin/certbot-auto renew

最后，我使用sudo bash测试了cron命令：

sudo bash -c "letsencrypt renew >> /var/log/letsencrypt/renew.log"

Answer 2

我最近（2018年4月）在Ubuntu 16.04服务器上安装并运行了certbot（版本0.22.2），并在/etc/cron.d/certbot中自动创建了续订cron作业。

这是创建的cron作业：

# /etc/cron.d/certbot: crontab entries for the certbot package
#
# Upstream recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc.  Renewal will only occur if expiration
# is within 30 days.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew

请在投入新的Cron工作之前检查一下。

Answer 3

在Debian Jessie及更高版本（包括Ubuntu）中，不执行cron来续订Certbot。而是使用systemd计时器。查看计时器：/lib/systemd/system/certbot.timer

此计时器运行以下服务：/lib/systemd/system/certbot.service

其中包含：

[Service]
Type=oneshot
ExecStart=/usr/bin/certbot -q renew
PrivateTmp=true

为了列出所有计时器，请在终端中执行以下命令：

systemctl list-timers

希望Certbot是其中的一部分：

星期一2019-02-04 08:38:45欧洲中部时间9h离开星期日2019-02-03 15:25:41欧洲中部时间 8小时前certbot.timer certbot.service

更新：

由于投了反对票。我将添加如何在基于Debian的发行版上安装Certbot（具体取决于您的Linux发行版）。

例如，在Debian Stretch中，您可以通过以下方式安装certbot的反向端口软件包：

sudo apt-get install certbot -t stretch-backports

这将自动为您安装上面显示的文件！从而自动为您安排一个certbot计时器，该计时器将运行服务，并再次运行续订。

始终可以通过以下方式手动运行续订：

sudo /usr/bin/certbot renew

可以通过--force-renewal标志来强制。有关更多信息，请参见续订帮助文本：

/usr/bin/certbot --help renew

certbot软件包的文件部分（包括但不限于）：

dpkg-query -L certbot
...
/lib/systemd/system/certbot.service
/lib/systemd/system/certbot.timer
...

Answer 4

通常，在Ubuntu 16.04服务器中为任何Web服务器运行certbot时，它会自动创建cron

#cat /etc/cron.d/certbot

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew

Answer 5

好的。因此，在使用systemd的Debian（或Ubuntu）上，我可能遇到了与其他人相同的问题-cron作业未触发。我需要做一些额外的步骤和观察，其他地方都没有提及，因此请单独回答。

在我的情况下，/etc/systemd/system/目录存在，因此/etc/cron.d/certbot中的作业在初始测试时停止。

但 /etc/systemd/system/certbot.timer是指向/dev/null的指针。这意味着它是一个 masked 计时器。当我做systemd unmask certbot.timer时，链接被删除了，但是我没有什么可以替换的（尝试locate certbot.timer，但是我的系统上没有安装）。我还可以在systemd list-timers --all中看到计时器，但这是一个空文件，因此也使用systemd disable certbot.timer将其删除。 /etc/systemd/system/certbot.service中的服务完全不存在。

因此，在从/etc/systemd/system/清除了所有与certbot相关的内容之后，我手动创建了必要的文件。

# /etc/systemd/system/certbot-renewal.service
[Unit]
Description=Certbot Renewal
[Service]
ExecStart=/usr/local/bin/certbot -q renew --post-hook "systemctl reload nginx"

# /etc/systemd/system/certbot-renewal.timer
[Unit]
Description=Run certbot twice daily

[Timer]
OnCalendar=*-*-* 00,12:00:00
RandomizedDelaySec=43200
Persistent=true

[Install]
WantedBy=timers.target

计时器文件的内容来自this answer。

我启动并通过运行检查了整个过程：

sudo systemctl start certbot-renewal.timer
sudo systemctl enable certbot-renewal.timer
sudo systemctl list-timers --all
sudo journalctl -u certbot-renewal.service

更多笔记：

我在/usr/local/bin/certbot中使用了certbot，而不是/usr/bin/certbot（使用which certbot来创建），不知道为什么。
我正在使用nginx，因此需要在挂机后重新加载它，以考虑到更新的证书。

Answer 6

我将以下行添加到/etc/crontab中，以每天在 00:00 和大约 16:40 < / strong>：

1 1 * * * root sleep ${RANDOM:0:3}m && /home/admin/certbot-auto renew --quiet --no-self-upgrade --authenticator webroot --installer apache -w /var/www/mywebroot

一年多以来效果很好。

renew命令本身可能因您而异-我当时使用的是webroot，因为它当时最强大。

如何安排让我们的加密证书机器人在cron中自动续订我的证书？

6 个答案: