LinuxCertbot续期与自动更新教程

Linux上Certbot自动续期看似简单，实则暗藏多重陷阱：它并非装完即用，而是依赖systemd定时器精准触发，且全程受证书配置、Web服务状态、文件权限、网络连通性及SELinux等多维度制约；多数失败源于定时器未启用、renewal配置域名不匹配、Nginx未运行或reload静默失败、post-hook脚本无执行权限、私钥权限错误或DNS/端口不可达等“隐形断点”，真正可靠的验证必须绕过--dry-run的假象，直击--force-renewal --dry-run+日志追踪+PID比对等实战手段——续期不是一次命令，而是一场四线协同的系统级运维。

Certbot 续期不是“手动点一下就行”，而是靠定时任务自动触发 certbot renew，但前提是它能连上 Let’s Encrypt、读到证书配置、改得了 Web 服务配置、并且证书没被锁死或权限卡住——绝大多数失败都卡在这几步。

怎么确认续期任务真在跑

很多人以为装完 Certbot 就万事大吉，其实得亲眼看到定时器在动。Rocky/Alma/CentOS 8+ 和 Ubuntu 20.04+ 默认用 systemd timer，不是 cron：

• 查是否启用：sudo systemctl is-enabled certbot.timer（应返回 enabled）
• 查最近执行记录：sudo systemctl list-timers --all | grep certbot，看 NEXT 和 LAST 时间是否合理（通常是每 12 小时一次）
• 手动触发一次：sudo systemctl start certbot.timer，再立刻查日志：sudo journalctl -u certbot -n 30 -f

如果 systemctl list-timers 里压根没 certbot，说明安装时没带插件（比如漏装 python3-certbot-nginx），或者 snap 安装后没建软链接：sudo ln -s /snap/bin/certbot /usr/bin/certbot。

为什么 certbot renew --dry-run 过了，真续期却失败

--dry-run 只模拟 ACME 协议通信和证书签发逻辑，不碰磁盘权限、不 reload 服务、也不检查 post-hook 脚本是否可执行——这些才是生产环境翻车重灾区：

• 证书路径被硬编码在 Nginx 配置里（比如写死 /etc/letsencrypt/live/example.com/fullchain.pem），但 renewal 配置里域名拼错，导致 renew 找不到对应配置文件，直接跳过该证书
• /etc/letsencrypt/renewal/example.com.conf 里 authenticator = nginx，但实际 Nginx 没运行，或配置被改过，certbot renew 会静默失败（日志里只有 Skipping example.com）
• post-hook 脚本（如 /etc/letsencrypt/renewal-hooks/post/reload-nginx.sh）没加执行权限：sudo chmod +x /etc/letsencrypt/renewal-hooks/post/reload-nginx.sh

真正要验证，得用：sudo certbot renew --force-renewal --dry-run（强制走完整流程，包括调用 hook），再配合 journalctl -u nginx 看 reload 是否成功。

证书更新后 Nginx 不重载？别只信 post-hook

很多人把 reload 命令塞进 post-hook 就以为高枕无忧，但 Nginx reload 失败不会中断续期流程，也不会报错到终端——它只会默默记在 /var/log/letsencrypt/letsencrypt.log 末尾：

• 常见原因：Nginx 配置语法错误（比如 SSL 指令写错位置）、privkey.pem 权限不对（必须是 600，且属主是 root）、或 SELinux 拦截（sudo setsebool -P httpd_can_network_connect 1）
• 更稳的做法：不用 post-hook，改用 --deploy-hook 参数启动 renew（支持单次命令指定），或直接在 systemd timer 的 ExecStart= 后追加：&& systemctl reload nginx
• 验证 reload 是否生效：sudo ss -tlnp | grep ':443' 看进程 PID 是否变化，比看日志更直接

哪些情况 certbot renew 会彻底跳过你的域名

不是所有放在 /etc/letsencrypt/live/ 下的域名都会被续——Certbot 只认 /etc/letsencrypt/renewal/ 下有对应 .conf 文件的域名，而且该文件必须满足：

• [[webroot_map]] 或 authenticator = nginx 配置项存在且有效
• 证书未过期超过 30 天（Let’s Encrypt 要求剩余有效期
• 域名 DNS 解析正常，且 80/443 端口对外可达（certbot renew 会尝试连接验证）
• 如果是用 --standalone 申请的，续期时必须确保 80 端口空闲（Nginx/Apache 得先停），否则直接失败

最省事的排查方式：sudo certbot certificates 列出所有受管证书，再对照 /etc/letsencrypt/renewal/ 下的 .conf 文件名——名字对不上，就等于 Certbot 根本不认识这个证书。

自动续期真正的难点从来不在命令怎么敲，而在于你得同时盯住证书配置、Web 服务状态、系统权限、网络通路四条线。少一条断了，certbot renew 就变成一个安静的摆设。

本篇关于《LinuxCertbot续期与自动更新教程》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！